Block-Chain Ledger Based Tracking of Generated Music Content

ABSTRACT

Techniques are disclosed relating to tracking contributions to composed music content. In some embodiments, a computer system determines playback data for a music content mix, where the playback data indicates characteristics of playback of the music content mix and the music content mix includes a determined combination of multiple audio tracks. In some embodiments, the system records, in an electronic block-chain ledger data structure, information specifying individual playback data for one or more of the multiple audio tracks in the music content mix. The information specifying individual playback data for an individual audio track may include usage data for the individual audio track and signature information associated with the individual audio track.

PRIORITY CLAIM

This application claims the benefit of U.S. Provisional Application No.62/972,711, filed on Feb. 11, 2020; U.S. Provisional Application No.63/028,233, filed May 21, 2020; U.S. Provisional Application No.63/068,431, filed Aug. 21, 2020; and U.S. Provisional Application No.63/068,433 filed Aug. 21, 2020, each of which is incorporated byreference herein in its entirety.

BACKGROUND Technical Field

This disclosure relates to audio engineering and more particularly togenerating music content.

Description of the Related Art

Streaming music services typically provide songs to users via theInternet. Users may subscribe to these services and stream music througha web browser or application. Examples of such services include PANDORA,SPOTIFY, GROOVESHARK, etc. Often, a user can select a genre of music orspecific artists to stream. Users can typically rate songs (e.g., usinga star rating or a like/dislike system), and some music services maytailor which songs are streamed to a user based on previous ratings. Thecost of running a streaming service (which may include paying royaltiesfor each streamed song) is typically covered by user subscription costsand/or advertisements played between songs.

Song selection may be limited by licensing agreements and the number ofsongs written for a particular genre. Users may become tired of hearingthe same songs in a particular genre. Further, these services may nottune music to users' tastes, environment, behavior, etc.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram illustrating an exemplary music generator.

FIG. 2 is a block diagram illustrating an exemplary overview of a systemfor generating output music content based on inputs from multipledifferent sources, according to some embodiments.

FIG. 3 is a block diagram illustrating an exemplary music generatorsystem configured to output music content based on analysis of imagerepresentations of audio files, according to some embodiments.

FIG. 4 depicts an example of an image representation of an audio file.

FIGS. 5A and 5B depict examples of greyscale images for a melody imagefeature representation and a drum beat image feature representation,respectively.

FIG. 6 is a block diagram illustrating an exemplary system configured togenerate a single image representation, according to some embodiments.

FIG. 7 depicts an example of a single image representation of multipleaudio files.

FIG. 8 is a block diagram illustrating an exemplary system configured toimplement user-created controls in music content generation, accordingto some embodiments.

FIG. 9 depicts a flowchart of a method for training a music generatormodule based on a user-created control element, according to someembodiments.

FIG. 10 is a block diagram illustrating an exemplary teacher/studentframework system, according to some embodiments.

FIG. 11 is a block diagram illustrating an exemplary system configuredto implement audio techniques in music content generation, according tosome embodiments.

FIG. 12 depicts an example of an audio signal graph.

FIG. 13 depicts an example of an audio signal graph.

FIG. 14 depicts an exemplary system for implementing real-timemodification of music content using an audio technique music generatormodule, according to some embodiments.

FIG. 15 depicts a block diagram of an exemplary API module in a systemfor automation of audio parameters, according to some embodiments.

FIG. 16 depicts a block diagram of an exemplary memory zone, accordingto some embodiments.

FIG. 17 depicts a block diagram of an exemplary system for storing newmusic content, according to some embodiments.

FIG. 18 is a diagram illustrating example playback data, according tosome embodiments.

FIG. 19 is a block diagram illustrating an example composition system,according to some embodiments.

FIGS. 20A-20B are block diagrams illustrating graphical user interfaces,according to some embodiments.

FIG. 21 is a block diagram illustrating an example music generatorsystem that includes analysis and composition modules, according to someembodiments.

FIG. 22 is a diagram illustrating an example buildup section of musiccontent, according to some embodiments.

FIG. 23 is a diagram illustrating example techniques for arrangingsections of music content, according to some embodiments.

FIG. 24 is a flow diagram method for using a ledger, according to someembodiments.

FIG. 25 is a flow diagram method for using image representations tocombine audio files, according to some embodiments.

FIG. 26 is a flow diagram method for implementing user-created controlelements, according to some embodiments.

FIG. 27 is a flow diagram method for generating music content bymodifying audio parameters, according to some embodiments.

Although the embodiments disclosed herein are susceptible to variousmodifications and alternative forms, specific embodiments are shown byway of example in the drawings and are described herein in detail. Itshould be understood, however, that drawings and detailed descriptionthereto are not intended to limit the scope of the claims to theparticular forms disclosed. On the contrary, this application isintended to cover all modifications, equivalents and alternativesfalling within the spirit and scope of the disclosure of the presentapplication as defined by the appended claims.

This disclosure includes references to “one embodiment,” “a particularembodiment,” “some embodiments,” “various embodiments,” or “anembodiment.” The appearances of the phrases “in one embodiment,” “in aparticular embodiment,” “in some embodiments,” “in various embodiments,”or “in an embodiment” do not necessarily refer to the same embodiment.Particular features, structures, or characteristics may be combined inany suitable manner consistent with this disclosure.

Reciting in the appended claims that an element is “configured to”perform one or more tasks is expressly intended not to invoke 35 U.S.C.§ 112(f) for that claim element. Accordingly, none of the claims in thisapplication as filed are intended to be interpreted as havingmeans-plus-function elements. Should Applicant wish to invoke Section112(f) during prosecution, it will recite claim elements using the“means for” [performing a function] construct.

As used herein, the term “based on” is used to describe one or morefactors that affect a determination. This term does not foreclose thepossibility that additional factors may affect the determination. Thatis, a determination may be solely based on specified factors or based onthe specified factors as well as other, unspecified factors. Considerthe phrase “determine A based on B.” This phrase specifies that B is afactor that is used to determine A or that affects the determination ofA. This phrase does not foreclose that the determination of A may alsobe based on some other factor, such as C. This phrase is also intendedto cover an embodiment in which A is determined based solely on B. Asused herein, the phrase “based on” is synonymous with the phrase “basedat least in part on.”

As used herein, the phrase “in response to” describes one or morefactors that trigger an effect. This phrase does not foreclose thepossibility that additional factors may affect or otherwise trigger theeffect. That is, an effect may be solely in response to those factors,or may be in response to the specified factors as well as other,unspecified factors.

As used herein, the terms “first,” “second,” etc. are used as labels fornouns that they precede, and do not imply any type of ordering (e.g.,spatial, temporal, logical, etc.), unless stated otherwise. As usedherein, the term “or” is used as an inclusive or and not as an exclusiveor. For example, the phrase “at least one of x, y, or z” means any oneof x, y, and z, as well as any combination thereof (e.g., x and y, butnot z). In some situations, the context of use of the term “or” may showthat it is being used in an exclusive sense, e.g., where “select one ofx, y, or z” means that only one of x, y, and z are selected in thatexample.

In the following description, numerous specific details are set forth toprovide a thorough understanding of the disclosed embodiments. Onehaving ordinary skill in the art, however, should recognize that aspectsof disclosed embodiments might be practiced without these specificdetails. In some instances, well-known, structures, computer programinstructions, and techniques have not been shown in detail to avoidobscuring the disclosed embodiments.

DETAILED DESCRIPTION

U.S. patent application Ser. No. 13/969,372, filed Aug. 16, 2013 (nowU.S. Pat. No. 8,812,144), which is incorporated by reference herein inits entirety, discusses techniques for generating music content based onone or more musical attributes. To the extent that any interpretation ismade based on a perceived conflict between definitions of the '372application and the remainder of the disclosure, the present disclosureis intended to govern. The musical attributes may be input by a user ormay be determined based on environment information such as ambientnoise, lighting, etc. The '372 disclosure discusses techniques forselecting stored loops and/or tracks or generating new loops/tracks, andlayering selected loops/tracks to generate output music content.

U.S. patent application Ser. No. 16/420,456, filed May 23, 2019 (nowU.S. Pat. No. 10,679,596), which is incorporated by reference herein inits entirety, discusses techniques for generating music content. To theextent that any interpretation is made based on a perceived conflictbetween definitions of the '456 application and the remainder of thedisclosure, the present disclosure is intended to govern. Music may begenerated based on input by a user or using computer-implementedmethods. The '456 disclosure discusses various music generatorembodiments.

The present disclosure generally relates to systems for generatingcustom music content by selecting and combining audio tracks based onvarious parameters. In various embodiments, machine learning algorithms(including neural networks such as deep learning neural networks) areconfigured to generate and customize music content to particular users.In some embodiments, users may create their own control elements and thecomputing system may be trained to generate output music contentaccording to a user's intended functionality of a user-defined controlelement. In some embodiments, playback data of music content generatedby techniques described herein may be recorded in order to record andtrack the usage of various music content by different rights-holders(e.g., copyright holders). The various techniques discussed below mayprovide more relevant custom music for different contexts, facilitategenerating music according to a particular sound, allow users morecontrol of how music is generated, generate music that achieves one ormore specific goals, generate music in real-time to accompany othercontent, etc.

As used herein, the term “audio file” refers to sound information formusic content. For instance, sound information may include data thatdescribes music content in as raw audio in a format such as way, aiff,or FLAC. Properties of the music content may be included in the soundinformation. Properties may include, for example, quantifiable musicalproperties such as instrument classification, pitch transcription, beattimings, tempo, file length, and audio amplitude in multiple frequencybins. In some embodiments, an audio file includes sound information overa particular time interval. In various embodiments, audio files includeloops. As used herein, the term “loop” refers to sound information for asingle instrument over a particular time interval. Various techniquesdiscussed with reference to audio files may also be performed usingloops that include a single instrument. Audio files or loops may beplayed in a repeated manner (e.g., a 30 second audio file may be playedfour times in a row to generate 2 minutes of music content), but audiofiles may also be played once, e.g., without being repeated.

In some embodiments, image representations of audio files are generatedand used to generate music content. Image representations of audio filesmay be generated based on data in the audio files and MIDIrepresentations of the audio files. The image representations may be,for example, two-dimensional (2D) image representations of pitch andrhythm determined from the MIDI representations of the audio files.Rules (e.g., composition rules) may be applied to the imagerepresentations to select audio files to be used to generate new musiccontent. In various embodiments, machine learning/neural networks areimplemented on the image representations to select the audio files forcombining to generate new music content. In some embodiments, the imagerepresentations are compressed (e.g., lower resolution) versions of theaudio files. Compressing the image representations can increase thespeed in searching for selected music content in the imagerepresentations.

In some embodiments, a music generator may generate new music contentbased on various parameter representations of the audio files. Forinstance, an audio file typically has an audio signal that can berepresented as a graph of the signal (e.g., signal amplitude, frequency,or a combination thereof) relative to time. The time-basedrepresentation, however, is dependent on the tempo of the music content.In various embodiments, the audio file is also represented using a graphof the signal relative to beats (e.g., a signal graph). The signal graphis independent to tempo, which allows for tempo invariant modificationof audio parameters of the music content.

In some embodiments, a music generator allows a user to create and labeluser-defined controls. For example, a user may create a control that themusic generator can then train to influence the music according to theuser's preferences. In various embodiments, user-defined controls arehigh-level controls such as controls that adjust mood, intensity, orgenre. Such controls are typically subjective measures that are based ona listener's individual preferences. In some embodiments, a user createsand labels a control for a user-defined parameter. The music generatormay then play various music files and allow the user to modify the musicaccording to the user-defined parameter. The music generator may learnand store the user's preferences based on the user's adjustment of theuser-defined parameter. Thus, during later playback, the user-definedcontrol for the user-defined parameter may be adjusted by the user andthe music generator adjusts the music playback according to the user'spreferences. In some embodiments, the music generator may also selectmusic content according to the user's preferences set by theuser-defined parameter.

In some embodiments, music content generated by the music generatorincludes music with various stakeholder entities (e.g., rights-holdersor copyright holders). In commercial applications with continuousplayback of the generated music content, remuneration based on theplayback of individual audio tracks (files) may be difficult. Thus, invarious embodiments, techniques are implemented for recording playbackdata of continuous music content. The recorded playback data may includeinformation pertaining to the playback time of individual audio trackswithin the continuous music content matched with the stakeholder foreach individual audio track. Additionally, techniques may be implementedto prevent tampering with the playback data information. For instance,the playback data information may be stored in a publicly accessible,immutable block-chain ledger.

This disclosure initially describes, with reference to FIGS. 1 and 2, anexample music generator module and an overall system organization withmultiple applications. Techniques for generating a music content fromimage representations are discussed with reference to FIGS. 3-7.Techniques for implementing user-created control elements are discussedwith reference to FIGS. 8 and 10. Techniques for generating implementingaudio techniques are discussed with reference to FIGS. 11-17. Techniquesfor recording information about generated music or elements inblockchains or other cryptographic ledgers are discussed with referenceto FIGS. 18-19. FIGS. 20A-20B show exemplary application interfaces.

Generally speaking, the disclosed music generator includes audio files,metadata (e.g., information describing the audio files), and a grammarfor combining audio files based on the metadata. The generator maycreate music experiences using rules to identify the audio files basedon metadata and target characteristics of the music experience. It maybe configured to expand the set of experiences it can create by addingor modifying rules, audio files, and/or metadata. The adjustments may beperformed manually (e.g., artists adding new metadata) or the musicgenerator may augment the rules/audio files/metadata as it monitors themusic experience within the given environment and goals/characteristicsdesired. For example, listener-defined controls may be implemented forgaining user feedback on music goals or characteristics.

Overview of Exemplary Music Generator

FIG. 1 is a diagram illustrating an exemplary music generator, accordingto some embodiments. In the illustrated embodiment, music generatormodule 160 receives various information from multiple different sourcesand generates output music content 140.

In the illustrated embodiment, module 160 accesses stored audio file(s)and corresponding attribute(s) 110 for the stored audio file(s) andcombines the audio files to generate output music content 140. In someembodiments, music generator module 160 selects audio files based ontheir attributes and combines audio files based on target musicattributes 130. In some embodiments, audio files may be selected basedon environment information 150 in combination with target musicattributes 130. In some embodiments, environment information is usedindirectly to determine target music attributes 130. In someembodiments, target music attributes 130 are explicitly specified by auser, e.g., by specifying a desired energy level, mood, multipleparameters, etc. For instance, listener-defined controls, describedherein, may be implemented to specify listener preferences used astarget music attributes. Examples of target music attributes 130 includeenergy, complexity, and variety, although more specific attributes(e.g., corresponding to the attributes of the stored tracks) may also bespecified. Speaking generally, when higher-level target music attributesare specified, lower-level specific music attributes may be determinedby the system before generating output music content.

Complexity may refer to a number of audio files, loops, and/orinstruments that are included in a composition. Energy may be related tothe other attributes or may be orthogonal to the other attributes. Forexample, changing keys or tempo may affect energy. However, for a giventempo and key, energy may be changed by adjusting instrument types(e.g., by adding high hats or white noise), complexity, volume, etc.Variety may refer to an amount of change in generated music over time.Variety may be generated for a static set of other musical attributes(e.g., by selecting different tracks for a given tempo and key) or maybe generated by changing musical attributes over time (e.g., by changingtempos and keys more often when greater variety is desired). In someembodiments, the target music attributes may be thought of as existingin a multi-dimensional space and music generator module 160 may slowlymove through that space, e.g., with course corrections, if needed, basedon environmental changes and/or user input.

In some embodiments, the attributes stored with the audio files containinformation about one or more audio files including: tempo, volume,energy, variety, spectrum, envelope, modulation, periodicity, rise anddecay time, noise, artist, instrument, theme, etc. Note that, in someembodiments, audio files are partitioned such that a set of one or moreaudio files is specific to a particular audio file type (e.g., oneinstrument or one type of instrument).

In the illustrated embodiment, module 160 accesses stored rule set(s)120. Stored rule set(s) 120, in some embodiments, specify rules for howmany audio files to overlay such that they are played at the same time(which may correspond to the complexity of the output music), whichmajor/minor key progressions to use when transitioning between audiofiles or musical phrases, which instruments to be used together (e.g.,instruments with an affinity for one another), etc. to achieve thetarget music attributes. Said another way, the music generator module160 uses stored rule set(s) 120 to achieve one or more declarative goalsdefined by the target music attributes (and/or target environmentinformation). In some embodiments, music generator module 160 includesone or more pseudo-random number generators configured to introducepseudo-randomness to avoid repetitive output music.

Environment information 150, in some embodiments, includes one or moreof: lighting information, ambient noise, user information (facialexpressions, body posture, activity level, movement, skin temperature,performance of certain activities, clothing types, etc.), temperatureinformation, purchase activity in an area, time of day, day of the week,time of year, number of people present, weather status, etc. In someembodiments, music generator module 160 does not receive/processenvironment information. In some embodiments, environment information150 is received by another module that determines target musicattributes 130 based on the environment information. Target musicattributes 130 may also be derived based on other types of content,e.g., video data. In some embodiments, environment information is usedto adjust one or more stored rule set(s) 120, e.g., to achieve one ormore environment goals. Similarly, the music generator may useenvironment information to adjust stored attributes for one or moreaudio files, e.g., to indicate target musical attributes or targetaudience characteristics for which those audio files are particularlyrelevant.

As used herein, the term “module” refers to circuitry configured toperform specified operations or to physical non-transitory computerreadable media that store information (e.g., program instructions) thatinstructs other circuitry (e.g., a processor) to perform specifiedoperations. Modules may be implemented in multiple ways, including as ahardwired circuit or as a memory having program instructions storedtherein that are executable by one or more processors to perform theoperations. A hardware circuit may include, for example, customvery-large-scale integration (VLSI) circuits or gate arrays,off-the-shelf semiconductors such as logic chips, transistors, or otherdiscrete components. A module may also be implemented in programmablehardware devices such as field programmable gate arrays, programmablearray logic, programmable logic devices, or the like. A module may alsobe any suitable form of non-transitory computer readable media storingprogram instructions executable to perform specified operations.

As used herein, the phrase “music content” refers both to music itself(the audible representation of music), as well as to information usableto play music. Thus, a song recorded as a file on a storage medium (suchas, without limitation a compact disc, flash drive, etc.) is an exampleof music content; the sounds produced by outputting this recorded fileor other electronic representation (e.g., through speakers) is also anexample of music content.

The term “music” includes its well-understood meaning, including soundsgenerated by musical instruments as well as vocal sounds. Thus, musicincludes, for example, instrumental performances or recordings, acappella performances or recordings, and performances or recordings thatinclude both instruments and voice. One of ordinary skill in the artwould recognize that “music” does not encompass all vocal recordings.Works that do not include musical attributes such as rhythm or rhyme—forexample, speeches, newscasts, and audiobooks—are not music.

One piece of music “content” can be distinguished from another piece ofmusic content in any suitable fashion. For example, a digital filecorresponding to a first song may represent a first piece of musiccontent, while a digital file corresponding to a second song mayrepresent a second piece of music content. The phrase “music content”can also be used to distinguish particular intervals within a givenmusical work, such that different portions of the same song can beconsidered different pieces of musical content. Similarly, differenttracks (e.g., piano track, guitar track) within a given musical work mayalso correspond to different pieces of musical content. In the contextof a potentially endless stream of generated music, the phrase “musiccontent” can be used to refer to some portion of the stream (e.g., a fewmeasures or a few minutes).

Music content generated by embodiments of the present disclosure may be“new music content”—combinations of musical elements that have neverbeen previously generated. A related (but more expansive)concept—“original music content”—is described further below. Tofacilitate the explanation of this term, the concept of a “controllingentity” relative to an instance of music content generation isdescribed. Unlike the phrase “original music content,” the phrase “newmusic content” does not refer to the concept of a controlling entity.Accordingly, new music content refers to music content that has neverbefore been generated by any entity or computer system.

Conceptually, the present disclosure refers to some “entity” ascontrolling a particular instance of computer-generated music content.Such an entity owns any legal rights (e.g., copyright) that mightcorrespond to the computer-generated content (to the extent that anysuch rights may actually exist). In one embodiment, an individual thatcreates (e.g., codes various software routines) a computer-implementedmusic generator or operates (e.g., supplies inputs to) a particularinstance of computer-implemented music generation will be thecontrolling entity. In other embodiments, a computer-implemented musicgenerator may be created by a legal entity (e.g., a corporation or otherbusiness organization), such as in the form of a software product,computer system, or computing device. In some instances, such acomputer-implemented music generator may be deployed to many clients.Depending on the terms of a license associated with the distribution ofthis music generator, the controlling entity may be the creator, thedistributor, or the clients in various instances. If there are no suchexplicit legal agreements, the controlling entity for acomputer-implemented music generator is the entity facilitating (e.g.,supplying inputs to and thereby operating) a particular instance ofcomputer generation of music content.

Within the meaning of the present disclosure, computer generation of“original music content” by a controlling entity refers to 1) acombination of musical elements that has never been generated before,either by the controlling entity or anyone else, and 2) a combination ofmusical elements that has been generated before, but was generated inthe first instance by the controlling entity. Content type 1) isreferred to herein as “novel music content,” and is similar to thedefinition of “new music content,” except that the definition of “novelmusic content” refers to the concept of a “controlling entity,” whilethe definition of “new music content” does not. Content type 2), on theother hand, is referred to herein as “proprietary music content.” Notethat the term “proprietary” in this context does not refer to anyimplied legal rights in the content (although such rights may exist),but is merely used to indicate that the music content was originallygenerated by the controlling entity. Accordingly, a controlling entity“re-generating” music content that was previously and originallygenerated by the controlling entity constitutes “generation of originalmusic content” within the present disclosure. “Non-original musiccontent” with respect to a particular controlling entity is musiccontent that is not “original music content” for that controllingentity.

Some pieces of music content may include musical components from one ormore other pieces of music content. Creating music content in thismanner is referred to as “sampling” music content, and is common incertain musical works, and particularly in certain musical genres. Suchmusic content is referred to herein as “music content with sampledcomponents,” “derivative music content,” or using other similar terms.In contrast, music content that does not include sampled components isreferred to herein as “music content without sampled components,”“non-derivative music content,” or using other similar terms.

In applying these terms, it is noted that if any particular musiccontent is reduced to a sufficient level of granularity, an argumentcould be made that this music content is derivative (meaning, in effect,that all music content is derivative). The terms “derivative” and“non-derivative” are not used in this sense in the present disclosure.With regard to the computer generation of music content, such computergeneration is said to be derivative (and result in derivative musiccontent) if the computer generation selects portions of components frompre-existing music content of an entity other than the controllingentity (e.g., the computer program selects a particular portion of anaudio file of a popular artist's work for inclusion in a piece of musiccontent being generated). On the other hand, computer generation ofmusic content is said to be non-derivative (and result in non-derivativemusic content) if the computer generation does not utilize suchcomponents of such pre-existing content. Note some pieces of “originalmusic content” may be derivative music content, while some pieces may benon-derivative music content.

It is noted that the term “derivative” is intended to have a broadermeaning within the present disclosure than the term “derivative work”that is used in U.S. copyright law. For example, derivative musiccontent may or may not be a derivative work under U.S. copyright law.The term “derivative” in the present disclosure is not intended toconvey a negative connotation; it is merely used to connote whether aparticular piece of music content “borrows” portions of content fromanother work.

Further, the phrases “new music content,” “novel music content,” and“original music content” are not intended to encompass music contentthat is only trivially different from a pre-existing combination ofmusical elements. For example, merely changing a few notes of apre-existing musical work does not result in new, novel, or originalmusic content, as those phrases are used in the present disclosure.Similarly, merely changing a key or tempo or adjusting a relativestrength of frequencies (e.g., using an equalizer interface) of apre-existing musical work does not produce new, novel, or original musiccontent. Moreover, the phrases, new, novel, and original music contentare not intended to cover those pieces of music content that areborderline cases between original and non-original content; instead,these terms are intended to cover pieces of music content that areunquestionably and demonstrably original, including music content thatwould be eligible for copyright protection to the controlling entity(referred to herein as “protectable” music content). Further, as usedherein, the term “available” music content refers to music content thatdoes not violate copyrights of any entities other than the controllingentity. New and/or original music content is often protectable andavailable. This may be advantageous in preventing copying of musiccontent and/or paying royalties for music content.

Although various embodiments discussed herein use rule-based engines,various other types of computer-implemented algorithms may be used forany of the computer learning and/or music generation techniquesdiscussed herein. Rule-based approaches may be particularly effective inthe music context, however.

Overview of Applications, Storage Elements, and Data that may be used inExemplary Music Systems

A music generator module may interact with multiple differentapplications, modules, storage elements, etc. to generate music content.For example, end users may install one of multiple types of applicationsfor different types of computing devices (e.g., mobile devices, desktopcomputers, DJ equipment, etc.). Similarly, another type of applicationmay be provided to enterprise users. Interacting with applications whilegenerating music content may allow the music generator to receiveexternal information that it may use to determine target musicattributes and/or update one or more rule sets used to generate musiccontent. In addition to interacting with one or more applications, amusic generator module may interact with other modules to receive rulesets, update rule sets, etc. Finally, a music generator module mayaccess one or more rule sets, audio files, and/or generated musiccontent stored in one or more storage elements. In addition, a musicgenerator module may store any of the items listed above in one or morestorage elements, which may be local or accessed via a network (e.g.,cloud-based).

FIG. 2 is a block diagram illustrating an exemplary overview of a systemfor generating output music content based on inputs from multipledifferent sources, according to some embodiments. In the illustratedembodiment, system 200 includes rule module 210, user application 220,web application 230, enterprise application 240, artist application 250,artist rule generator module 260, storage of generated music 270, andexternal inputs 280.

User application 220, web application 230, and enterprise application240, in the illustrated embodiment, receive external inputs 280. In someembodiments, external inputs 280 include: environment inputs, targetmusic attributes, user input, sensor input, etc. In some embodiments,user application 220 is installed on a user's mobile device and includesa graphical user interface (GUI) that allows the user tointeract/communicate with rule module 210. In some embodiments, webapplication 230 is not installed on a user device, but is configured torun within a browser of a user device and may be accessed through awebsite. In some embodiments, enterprise application 240 is anapplication used by a larger-scale entity to interact with a musicgenerator. In some embodiments, application 240 is used in combinationwith user application 220 and/or web application 230. In someembodiments, application 240 communicates with one or more externalhardware devices and/or sensors to collect information concerning thesurrounding environment.

Rule module 210, in the illustrated embodiment, communicates with userapplication 220, web application 230, and enterprise application 240 toproduce output music content. In some embodiments, music generator 160is included in rule module 210. Note that rule module 210 may beincluded in one of applications 220, 230, and 240 or may be installed ona server and accessed via a network. In some embodiments, applications220, 230, and 240 receive generated output music content from rulemodule 210 and cause the content to be played. In some embodiments, rulemodule 210 requests input from applications 220, 230, and 240 regardingtarget music attributes and environment information, for example, andmay use this data to generate music content.

Stored rule set(s) 120, in the illustrated embodiment, are accessed byrule module 210. In some embodiments, rule module 210 modifies and/orupdates stored rule set(s) 120 based on communicating with applications220, 230, and 240. In some embodiments, rule module 210 accesses storedrule set(s) 120 to generate output music content. In the illustratedembodiment, stored rule set(s) 120 may include rules from artist rulegenerator module 260, discussed in further detail below.

Artist application 250, in the illustrated embodiment, communicates withartist rule generator module 260 (which may be part of the sameapplication or may be cloud-based, for example). In some embodiments,artist application 250 allows artists to create rule sets for theirspecific sound, e.g., based on previous compositions. This functionalityis further discussed U.S. Pat. No. 10,679,596. In some embodiments,artist rule generator module 260 is configured to store generated artistrule sets for use by rule module 210. Users may purchase rule sets fromparticular artists before using them to generate output music via theirparticular application. The rule set for a particular artist may bereferred to as a signature pack.

Stored audio file(s) and corresponding attribute(s) 110, in theillustrated embodiment, are accessed by module 210 when applying rulesto select and combine tracks to generate output music content. In theillustrated embodiment, rule module 210 stores generated output musiccontent 270 in a storage element.

In some embodiments, one or more of the elements of FIG. 2 areimplemented on a server and accessed via a network, which may bereferred to as a cloud-based implementation. For example, stored ruleset(s) 120, audio file(s)/attribute(s) 110, and generated music 270 mayall be stored on the cloud and accessed by module 210. In anotherexample, module 210 and/or module 260 may also be implemented in thecloud. In some embodiments, generated music 270 is stored in the cloudand digitally watermarked. This may allow detection of copying generatedmusic, for example, as well as generating a large amount of custom musiccontent.

In some embodiments, one or more of the disclosed modules are configuredto generate other types of content in addition to music content. Forexample, the system may be configured to generate output visual contentbased on target music attributes, determined environmental conditions,currently-used rule sets, etc. As another example, the system may searcha database or the Internet based on current attributes of the musicbeing generated and display a collage of images that dynamically changesas the music changes and matches the attributes of the music.

Exemplary Machine Learning Approaches

As described herein, music generator module 160, shown in FIG. 1, mayimplement a variety of artificial intelligence (AI) techniques (e.g.,machine learning techniques) to generate output music content 140. Invarious embodiments, AI techniques implemented include a combination ofdeep neural networks (DNN) with more traditional machine learningtechniques and knowledge-based systems. This combination may align therespective strengths and weaknesses of these techniques with challengesinherent in music composition and personalization systems. Music contenthas structure at multiple levels. For instance, a song has sections,phrases, melodies, notes and textures. DNNs may be effective atanalyzing and generating very high level and very low level details ofmusic content. For example, DNNs may be good at classifying the textureof a sound as belonging to a clarinet or an electric guitar at a lowlevel or detecting verses and choruses at a high level. The middlelevels of music content details, such as the construction of melodies,orchestration, etc. may be more difficult. DNNs are typically good atcapturing a wide range of styles in a single model and thus, DNNs may beimplemented as generative tools that have a lot of expressive range.

In some embodiments, music generator module 160 utilizes expertknowledge by having human-composed audio files (e.g., loops) as thefundamental unit of music content used by the music generator module.For example, social context of expert knowledge may be embedded throughthe choice of rhythms, melodies and textures to record heuristics inmultiple levels of structure. Unlike the separation of DNN andtraditional machine learning based on a structural level, expertknowledge may be applied in any areas where musicality can be increasedwithout placing too strong of limitations on the trainability of musicgenerator module 160.

In some embodiments, music generator module 160 uses DNNs to findpatterns of how layers of audio are combined vertically, by layeringsounds on top of each other, and horizontally, by combining audio filesor loops into sequences. For example, music generator module 160 mayimplement an LSTM (long short-term memory) recurrent neural network,trained on MFCC (Mel-frequency cepstral coefficient) audio features ofloops used in multitrack audio recordings. In some embodiments, anetwork is trained to predict and select audio features of loops forupcoming beats based on knowledge of the audio features of previousbeats. For example, the network may be trained to predict the audiofeatures of loops for the next 8 beats based on knowledge of the audiofeatures of the last 128 beats. Thus, the network is trained to utilizea low-dimension feature representation to predict upcoming beats.

In certain embodiments, music generator module 160 uses known machinelearning algorithms for assembling sequences of multitrack audio intomusical structures with dynamics of intensity and complexity. Forinstance, music generator module 160 may implement Hierarchical HiddenMarkov Models, which may behave like state machines that make statetransitions with probabilities determined by multiple levels ofhierarchical structure. As an example, a specific kind of drop may bemore likely to happen after a buildup section but less likely if the endof that buildup does not have drums. In various embodiments, theprobabilities may be trained transparently, which is in contrast to theDNN training where what is being learned is more opaque.

A Markov Model may deal with larger temporal structures and thus may noteasily be trained by presenting example tracks as the examples may betoo long. A feedback control element (such as a thumbs up/down on theuser interface) may be used to give feedback on the music at any time.In certain embodiments, the feedback control element is implemented asone of UI control element(s) 830, shown in FIG. 8. Correlations betweenthe music structure and the feedback may then be used to updatestructural models used for composition, such as transition tables orMarkov models. This feedback may also be collected directly frommeasurements of heart-rate, sales, or any other metric where the systemis able to determine a clear classification. Expert knowledgeheuristics, described above, are also designed to be probabilistic wherepossible and trained in the same way as the Markov model.

In certain embodiments, training may be performed by composers or DJs.Such training may be separate from listener training. For example,training done by listeners (such as typical users) may be limited toidentifying correct or incorrect classification based on positive andnegative model feedback, respectively. For composers and DJs, trainingmay include hundreds of timesteps and include details on layers used andvolume control to give more explicit detail into what is driving changesin music content. For example, training performed by composers and DJsmay include sequence prediction training similar to global training ofDNNs, described above.

In various embodiments, a DNN is trained by taking in multi-track audioand interface interactions to predict what a DJ or composer will donext. In some embodiments, these interactions may be recorded and usedto develop new heuristics that are more transparent. In someembodiments, the DNN receives a number of previous measures of music asinput and utilizes a low-dimension feature representation, as describedabove, with additional features that describe modifications to a trackthat a DJ or composer has applied. For example, the DNN may receive thelast 32 measures of music as input and utilize the low-dimension featurerepresentation along with additional features to describe modificationsto the track that a DJ or composer has applied. These modifications mayinclude adjustments to gain of a particular track, filters applied,delay, etc. For example, a DJ may use the same drum loop repeated forfive minutes during a performance but may gradually increase the gainand delay on the track over time. Therefore, the DNN may be trained topredict such gain and delay changes in addition to loop selection. Whenno loops are played for a particular instrument (e.g., no drum loops areplayed), the feature set may be all zeros for that instrument, which mayallow the DNN to learn that predicting all zeros may be a successfulstrategy, which can lead to selective layering.

In some instances, DJs or composers record live performances usingmixers and devices such as TRAKTOR (Native Instruments GmbH). Theserecordings are typically captured in high resolution (e.g., 4 trackrecording or MIDI). In some embodiments, the system disassembles therecording into its constituent loops yielding information about thecombination of loops in a composition as well as the sonic qualities ofeach individual loop. Training the DNN (or other machine learning) withthis information provides the DNN with the ability to correlate bothcomposition (e.g., sequencing, layering, timing of loops, etc.) andsonic qualities of loops to inform music generator module 160 how tocreate music experiences that are similar to the artists performancewithout using the actual loops the artist used in their performance.

Exemplary Music Generator Using Image Representations of Audio Files

Music with wide popularity often has combinations of rhythm, texture,and pitch that are widely observed. When creating music note by note foreach instrument in a composition (as may be done by a music generator),rules may be implemented based on these combinations to create coherentmusic. Generally, the more rigid the rules, the less room is given forcreative variation, thus making it more likely to create copies ofexisting music.

When music is created through a combination of music phrases alreadyperformed and recorded as audio, multiple, unchangeable combinations ofnotes in each phrase may need to be considered for creating thecombination. When drawing from a library of thousands of audiorecordings, however, a search of every possible combination may becomputationally expensive. Additionally, note by note comparisons mayneed to be made to check for harmonically dissonant combinations,especially on the beat. New rhythms created by combining multiple filesmay also be checked against rules for rhythmic makeup of the combinedphrases.

Extracting the necessary features to make combinations from audio filesmay not always be possible. Even when possible, extracting the featuresneeded from audio files may be computationally expensive. In variousembodiments, symbolic audio representations are used for musiccomposition to reduce computational expenses. Symbolic audiorepresentations may rely on the music composer's memory of instrumentaltexture and stored rhythm and pitch information. A common format ofsymbolic music representation is MIDI. MIDI contains precise timing,pitch, and performance control information. In some embodiments, MIDImay be simplified and compressed further through piano rollrepresentations in which notes are shown as bars on a discretetime/pitch graph, typically with 8 octaves of pitch.

In some embodiments, a music generator is configured to generate outputmusic content by generating image representations of audio files andselecting combinations of music based on analysis of the imagerepresentations. Image representations may be representations that arefurther compressed from piano roll representations. For example, imagerepresentations may be lower resolution representations generated basedon MIDI representations of audio files. In various embodiments,composition rules are applied to the image representations to selectmusic content from the audio files to combine and generate output musiccontent. The composition rules may be applied, for example, usingrules-based methods. In some embodiments, machine learning algorithms ormodels (such as deep learning neural networks) are implemented to selectand combine audio files for generating output music content.

FIG. 3 is a block diagram illustrating an exemplary music generatorsystem configured to output music content based on analysis of imagerepresentations of audio files, according to some embodiments. In theillustrated embodiment, system 300 includes image representationgeneration module 310, music selection module 320, and music generatormodule 160.

Image representation generation module 310, in the illustratedembodiment, is configured to generate one or more image representationsof audio files. In certain embodiments, image representation generationmodule 310 receives audio file data 312 and MIDI representation data314. MIDI representation data 314 includes MIDI representation(s) ofspecified audio file(s) in audio file data 312. For instance, for aspecified audio file in audio file data 312 may have a correspondingMIDI representation in MIDI representation data 314. In some embodimentswith multiple audio files in audio file data 312, each audio file inaudio file data 312 has a corresponding MIDI representation in MIDIrepresentation data 314. In the illustrated embodiment, MIDIrepresentation data 314 is provided to image representation generationmodule 310 along with audio file data 312. In some contemplatedembodiments, however, image representation generation module 310 maygenerate MIDI representation data 314 on its own from audio file data312.

As shown in FIG. 3, image representation generation module 310 generatesimage representation(s) 316 from audio file data 312 and MIDIrepresentation data 314. MIDI representation data 314 may include pitch,time (or rhythm), and velocity (or note intensity) data for notes in themusic associated with an audio file while audio file data 312 includesdata for playback of the music itself. In certain embodiments, imagerepresentation generation module 310 generates an image representationfor an audio file based on the pitch, time, and velocity data from MIDIrepresentation data 314. The image representation may be, for example, atwo-dimensional (2D) image representation of an audio file. In the 2Dimage representation of an audio file, the x-axis represents time(rhythm) and the y-axis represents pitch (similar to a piano rollrepresentation) with values of the pixels at each x-y coordinaterepresenting velocity.

The 2D image representation of an audio file may have a variety of imagesizes, though the image size is typically selected to correspond tomusical structure. For instance, in one contemplated embodiment, a 2Dimage representation is a 32 (x-axis)×24 image (y-axis). A 32 pixelswide image representation allows each pixel to represent a quarter of abeat in the temporal dimension. Thus, 8 beats of music may berepresented by the 32 pixels wide image representation. While thisrepresentation may not have enough detail to capture expressive detailsof the music in an audio file, the expressive details are retained inthe audio file itself, which is used in combination with the imagerepresentation by system 300 for the generation of output music content.Quarter beat temporal resolution does, however, allow for significantcoverage of common pitch and rhythm combination rules.

FIG. 4 depicts an example of an image representation 316 of an audiofile. Image representation 316 is 32 pixels wide (for time) and 24pixels high (for pitch). Each pixel (square) 402 has a value thatrepresents the velocity for that time and pitch in the audio file. Invarious embodiments, image representation 316 may be a greyscale imagerepresentation of an audio file where pixel values are represented byvarying intensity of grey. The variations in grey, based on pixelvalues, may be small and imperceptible to many people. FIGS. 5A and 5Bdepict examples of greyscale images for a melody image featurerepresentation and a drum beat image feature representation,respectively. Other representations (e.g., color or numeric) may,however, also be contemplated. In these representations, each pixel mayhave multiple different values corresponding to different musicattributes.

In certain embodiments, image representation 316 is an 8-bitrepresentation of the audio file. Thus, each pixel may have 256 possiblevalues. A MIDI representation typically has 128 possible values forvelocity. In various embodiments, the detail in velocity values may beless important than the task of selecting audio files for combination.Thus, in such embodiments, the pitch axis (y-axis) may be banded tocover into two sets of octaves in an 8 octaves range with 4 octaves ineach set. For example, the 8 octaves can be defined as follows:

-   -   Octave 0: rows 0-11, values 0-63;    -   Octave 1: rows 12-23, values 0-63;    -   Octave 2: rows 0-11, values 64-127;    -   Octave 3: rows 12-23, values 64-127;    -   Octave 4: rows 0-11, values 128-191;    -   Octave 5: rows 12-23, values 128-191    -   Octave 6: rows 0-11, values 192-255; and    -   Octave 7: rows 12-23, values 192-255.

With these defined ranges for the octaves, the row and value of a pixeldetermines a note's octave and velocity. For instance, a pixel value of10 in row 1 represents a note in octave 0 with a velocity of 10 while apixel value of 74 in row 1 represents a note in octave 2 with a velocityof 10. As another example, a pixel value of 79 in row 13 represents anote in octave 3 with a velocity of 15 while a pixel value of 207 in row13 represents a note in octave 7 with a velocity of 15. Thus, using thedefine ranges for octaves above, the first 12 rows (rows 0-11) representa first set of 4 octaves (octaves 0, 2, 4, and 6) with the pixel valuedetermining which one of the first 4 octaves is represented (the pixelvalue also determining the velocity of the note). Similarly, the second12 rows (rows 12-23) represent a second set of 4 octaves (octaves 1, 3,5, and 7) with the pixel value determining which one of the second 4octaves is represented (the pixel value also determining the velocity ofthe note).

By banding the pitch axis to cover an 8 octaves range, as describedabove, the velocity of each octave may be defined by 64 values ratherthan the 128 values of a MIDI representation. Thus, the 2D imagerepresentation (e.g., image representation 316) may be compressed (e.g.,have a lower resolution) than the MIDI representation of the same audiofile. In some embodiments, further compression of the imagerepresentation may be allowed as 64 values may be more than is needed bysystem 300 to select music combinations. For instance, velocityresolution may be reduced further to allow compression in a temporalrepresentation by having odd pixel values represent note starts and evenpixel values representing note sustains. Reducing the resolution in thismanner allows for two notes with the same velocity played in quicksuccession to be distinguished from one longer note based on odd or evenpixel values.

The compactness of the image representation, as described above, reducesthe size of files needed for representation of the music (for example,as compared to MIDI representations). Thus, implementing imagerepresentations of audio files reduces the amount of disk storageneeded. Further, compressed image representations may be stored in highspeed memory that allows quick searches for possible music combinations.For instance, 8-bit image representations may be stored in graphicsmemory on a computer device, thus allowing large parallel searches to beimplemented together.

In various embodiments, image representations generated for multipleaudio files are combined into a single image representation. Forinstance, image representations for tens, hundreds, or thousands ofaudio files may be combined into a single image representation. Thesingle image representation may be a large, searchable image that can beused for parallel searching of the multiple audio files making up thesingle image. For example, the single image may be search in a similarmanner to a large texture in a video game using software such asMegaTextures (from id Software).

FIG. 6 is a block diagram illustrating an exemplary system configured togenerate a single image representation, according to some embodiments.In the illustrated embodiment, system 600 includes single imagerepresentation generation module 610 and texture feature extractionmodule 620. In certain embodiments, single image representationgeneration module 610 and texture feature extraction module 620 arelocated in image representation generation module 310, shown in FIG. 3.Single image representation generation module 610 or texture featureextraction module 620 may, however, be located outside of imagerepresentation generation module 310.

As shown in the illustrated embodiment of FIG. 6, multiple imagerepresentations 316A-N are generated. Image representations 316A-N maybe N number of individual image representations for N number ofindividual audio files. Single image representation generation module610 may combine individual image representations 316A-N into a single,combined image representation 316. In some embodiments, individual imagerepresentations combined by single image representation generationmodule 610 include individual image representations for differentinstruments. For instance, different instruments within an orchestra maybe represented by individual image representations, which are thencombined into a single image representation for searching and selectionof music.

In certain embodiments, the individual image representations 316A-N arecombined into single image representation 316 with the individual imagerepresentations placed adjacent each other without overlap. Thus, singleimage representation 316 is a complete data set representation of allindividual image representations 316A-N without loss of data (e.g.,without any data from one image representation modifying data foranother image representation). FIG. 7 depicts an example of a singleimage representation 316 of multiple audio files. In the illustratedembodiment, single image representation 316 is a combined imagegenerated from individual image representations 316A, 316B, 316C, and316D.

In some embodiments, single image representation 316 is appended withtexture features 622. In the illustrated embodiment, texture features622 are appended as a single row to single image representation 316.Turning back to FIG. 6, texture features 622 are determined by texturefeature extraction module 620. Texture features 622 may include, forexample, instrumental textures of music in audio files. For instance,texture features may include features from different instruments such asdrums, stringed instruments, etc.

In certain embodiments, texture feature extraction module 620 extractstexture features 622 from audio files data 312. Texture featureextraction module 620 may implement, for example, rules-based methods,machine learning algorithms or models, neural networks, or other featureextraction techniques to determine texture features from audio filesdata 312. In some embodiments, texture feature extraction module 620 mayextract texture features 622 from image representation(s) 316 (e.g.,either multiple image representations or a single image representation).For instance, texture feature extraction module 620 may implementimage-based analysis (such as image-based machine learning algorithms ormodels) to extract texture features 622 from image representation(s)316.

The addition of texture features 622 to single image representation 316provides the single image representation with additional informationthat is not typically available in MIDI representations or piano rollrepresentations of audio files. In some embodiments, the row withtexture features 622 in single image representation 316 (shown in FIG.7) may not need to be human readable. For instance, texture features 622may only need to be machine readable for implementation in a musicgeneration system. In certain embodiments, texture features 622 areappended to single image representation 316 for use in image-basedanalysis of the single image representation. For example, texturefeatures 622 may be used by image-based machine learning algorithms ormodels used in the selection of music, as described below. In someembodiments, texture features 622 may be ignored during the selection ofmusic, for example, in rules-based selections, as described below.

Turning back to FIG. 3, in the illustrated embodiment, imagerepresentation(s) 316 (e.g., either multiple image representations or asingle image representation) is provided to music selection module 320.Music selection module 320 may select audio files or portions of audiofiles to be combined in music generator module 160. In certainembodiments, music selection module 320 applies rules-based methods tosearch and select audio files or portions of audio files for combinationby music generator module 160. As shown in FIG. 3, music selectionmodule 320 accesses rules for rules-based methods from stored ruleset(s) 120. For example, rules accessed by music selection module 320may include rules for searching and selection such as, but not limitedto, composition rules and note combination rules. Applying rules toimage representation(s) 316 may be implemented using graphics processingavailable on a computer device.

For example, in various embodiments, note combination rules may beexpressed as vector and matrix calculations. Graphics processing unitsare typically optimized for making vector and matrix calculations. Forinstance, notes one pitch step apart may be typically dissonant andfrequently avoided. Notes such as these may be found by searching forneighboring pixels in additively layered images (or segments of a largeimage) based on rules. Therefore, in various embodiments, disclosedmodules may invoke kernels to perform all or a portion of the disclosedoperations on a graphics processor of a computing device.

In some embodiments, the banding of pitch in image representations,described above, allows the use of graphics processing for implantationof high-pass or low-pass filtering of audio. Removing (e.g., filteringout) pixel values below a threshold may simulate high-pass filteringwhile removing pixel values above a threshold value may simulatelow-pass filtering. For instance, filtering out (removing) pixel valueslower than 64 in the above banding example may have a similar effect asapplying a high-pass filter with a shelf at B1 by removing octaves 0 and1 in the example. Thus, the use of filters on each audio file can beefficiently simulated by applying rules on image representations ofaudio files.

In various embodiments, when audio files are layered together to createmusic, the pitch of a specified audio file may be changed. Changing thepitch may both open up a much larger range of possible successfulcombinations and the search space for combinations. For instance, eachaudio file can be tested in 12 different pitch shifted keys. Offsettingthe row order in an image representation when parsing images, andadjusting for octave shift, if necessary, may allow optimized searchingthrough these combinations.

In certain embodiments, music selection module 320 implements machinelearning algorithms or models on image representation(s) 316 to searchand select audio files or portions of audio files for combination bymusic generator module 160. Machine learning algorithms/models mayinclude, for example, deep learning neural networks or other machinelearning algorithms that classify images based on training of thealgorithms. In such embodiments, music selection module 320 includes oneor more machine learning models that are trained based on combinationsand sequences of audio files providing desired musical properties.

In some embodiments, music selection module 320 includes machinelearning models that continually learn during selection of output musiccontent. For instance, the machine learning models may receive userinput or other input reflecting properties of the output music contentthat can be used to adjust classification parameters implemented by themachine learning models. Similar to rules-based methods, machinelearning models may be implemented using graphics processing units on acomputer device.

In some embodiments, music selection module 320 implements a combinationof rules-based methods and machine learning models. In one contemplatedembodiment, a machine learning model is trained to find combinations ofaudio files and image representations for beginning a search for musiccontent to combine where the search is implemented using rules-basedmethods. In some embodiments, music selection module 320 tests forharmony and rhythm rule coherence in music selected for combination bymusic generator module 160. For example, music selection module 320 maytest for harmony and rhythm in selected audio files 322 before providingthe selected audio files to music generator module 160, as describedbelow.

In the illustrated embodiment of FIG. 3, music selected by musicselection module 320, as described above, is provided to music generatormodule 160 as selected audio files 322. Selected audio files 322 mayinclude complete or partial audio files that are combined by musicgenerator module 160 to generate output music content 140, as describedherein. In some embodiments, music generator module 160 accesses storedrule set(s) 120 to retrieve rules applied to selected audio files 322for generating output music content 140. The rules retrieved by musicgenerator module 160 may be different than the rules applied by musicselection module 320.

In some embodiments, selected audio files 322 includes information forcombining the selected audio files. For example, a machine learningmodel implemented by music selection module 320 may provide an outputwith instructions describing how music content is to be combined inaddition to the selection of the music to combine. These instructionsmay then be provided to music generator module 160 and implemented bythe music generator module for combining the selected audio files. Insome embodiments, music generator module 160 tests for harmony andrhythm rule coherence before finalizing output music content 140. Suchtests may be in addition to or in lieu of tests implemented by musicselection module 320.

Exemplary Controls for Music Content Generation

In various embodiments, as described herein, a music generator system isconfigured to automatically generate output music content by selectingand combining audio tracks based on various parameters. As describedherein, machine learning models (or other AI techniques) are used togenerate music content. In some embodiments, AI techniques areimplemented to customize music content for particular users. Forinstance, the music generator system may implement various types ofadaptive controls for personalizing music generation. Personalizing themusic generation allows content control by composer or listeners inaddition to content generation by AI techniques. In some embodiments,users create their own control elements, which the music generatorsystem may train (e.g., using AI techniques) to generate output musiccontent according to a user's intended functionality of a user-createdcontrol element. For example, a user may create a control element thatthe music generator system then trains to influence the music accordingto the user's preferences.

In various embodiments, user-created control elements are high-levelcontrols such as controls that adjust mood, intensity, or genre. Suchuser-created control elements are typically subjective measures that arebased on a listener's individual preferences. In some embodiments, auser labels a user-created control element to define a user-specifiedparameter. The music generator system may play various music content andallow the user to modify the user-specified parameter in the musiccontent using the control element. The music generator system may learnand store the manner in which the user-defined parameter varies audioparameters in the music content. Thus, during later playback, theuser-created control element may be adjusted by the user and the musicgenerator system adjusts audio parameters in the music playbackaccording to the adjustment level of the user-specified parameter. Insome contemplated embodiments, the music generator system may alsoselect music content according to the user's preferences set by theuser-specified parameter.

FIG. 8 is a block diagram illustrating an exemplary system configured toimplement user-created controls in music content generation, accordingto some embodiments. In the illustrated embodiment, system 800 includesmusic generator module 160 and user interface (UI) module 820. Invarious embodiments, music generator module 160 implements techniquesdescribed herein for generating output music content 140. For instance,music generator module 160 may access stored audio file(s) 810 andgenerate output music content 140 based on stored rule set(s) 120.

In various embodiments, music generator module 160 modifies musiccontent based on input from one or more UI control elements 830implemented in UI module 820. For instance, a user may adjust a level ofcontrol element(s) 830 during interaction with UI module 820. Examplesof control elements include, but are not limited to, sliders, dials,buttons, or knobs. The level of control element(s) 830 then sets controlelement level(s) 832, which are provided to music generator module 160.Music generator module 160 may then modify output music content 140based on control element level(s) 832. For example, music generatormodule 160 may implement AI techniques to modify output music content140 based on control element level(s) 830.

In certain embodiments, one or more of control element(s) 830 is auser-defined control element. For instance, a control element may bedefined by a composer or a listener. In such embodiments, a user maycreate and label a UI control element that specifies a parameter thatthe user wants to implement to control output music content 140 (e.g.,the user creates a control element for controlling a user-specifiedparameter in control output music content 140).

In various embodiments, music generator module 160 may learn or betrained to influence output music content 140 in a specified way basedon input from the user-created control element. In some embodiments,music generator module 160 is trained to modify audio parameters inoutput music content 140 based on a level of the user-created controlelement set by a user. Training music generator module 160 may include,for example, determining a relationship between audio parameters inoutput music content 140 and a level of the user-created controlelement. The relationship between the audio parameters in output musiccontent 140 and the level of the user-created control element may thenbe utilized by music generator module 160 to modify output music content140 based on an input level of the user-created control element.

FIG. 9 depicts a flowchart of a method for training music generatormodule 160 based on a user-created control element, according to someembodiments. Method 900 begins with a user creating and labelling acontrol element in 910. For example, as described above, a user maycreate and label a UI control element for controlling a user-specifiedparameter in output music content 140 generated by music generatormodule 160. In various embodiments, the label of the UI control elementdescribes the user-specified parameter. For example, a user may label acontrol element as “Attitude” to specify that the user wants to controlattitude (as defined by the user) in generated music content.

After creation of the UI control element, method 900 continues withplayback session 915. Playback session 915 may be used to train a system(e.g., music generator module 160) how to modify audio parameters basedon a level of the user-created UI control element. In playback session915, an audio track is played in 920. The audio track may be a loop orsample of music from an audio file stored on the device or accessed bythe device.

In 930, the user provides input on his/her interpretation of theuser-specified parameter in the audio track being played. For instance,in certain embodiments, the user is asked listen to the audio track andto select a level of the user-specified parameter that the user believesdescribes the music in the audio track. The level of the user-specifiedparameter may be selected, for example, using the user-created controlelement. This process may be repeated for multiple audio tracks inplayback session 915 to generate multiple data points for levels of theuser-specified parameter.

In some contemplated embodiments, the user may be asked to listen tomultiple audio tracks at a single time and comparatively rate the audiotracks based on the user-defined parameter. For instance, in the exampleof a user-created control defining “attitude”, the user may listen tomultiple audio tracks and the select which audio tracks have more“attitude” and/or which audio tracks have less “attitude”. Each of theselections made by the user may be a data point for a level of theuser-specified parameter.

After playback session 915 is completed, levels of audio parameters inthe audio tracks from the playback session are assessed in 940. Examplesof audio parameters include, but are not limited to, volume, tone, bass,treble, reverb, etc. In some embodiments, levels of audio parameters inthe audio tracks are assessed as an audio track is played (e.g., duringplayback session 915). In some embodiments, audio parameters areassessed after playback session 915 ends.

In various embodiments, audio parameters in the audio tracks areassessed from metadata for the audio tracks. For instance, audioanalysis algorithms may be used to generate metadata or symbolic musicdata (such as MIDI) for the audio tracks (which may be short,prerecorded music files). Metadata may include, for example, notepitches present in the recording, onsets-per-beat, ratio of pitched tounpitched sounds, volume level and other quantifiable properties ofsound.

In 950, a correlation between the user-selected levels for theuser-specified parameters and the audio parameters is determined. As theuser-selected levels for the user-specified parameters correspond tolevels of the control element, the correlation between the user-selectedlevels for the user-specified parameters and the audio parameters may beutilized to define a relationship between the levels of the one or moreaudio parameters and the level of the control element in 960. In variousembodiments, the correlation between the user-selected levels for theuser-specified parameters and the audio parameters and the relationshipbetween the levels of the one or more audio parameters and the level ofthe control element are determined using AI techniques (e.g., regressivemodels or machine learning algorithms).

Turning back to FIG. 8, the relationship between the levels of the oneor more audio parameters and the level of the control element may thenbe implemented by music generator module 160 to determine how to adjustaudio parameters in output music content 140 based on input of controlelement level 832 received from a user-created control element 830. Incertain embodiments, music generator module 160 implements machinelearning algorithms to generate output music content 140 based on inputof control element level 832 received from a user-created controlelement 830 and the relationship. For example, machine learningalgorithms may analyze how the metadata descriptions of audio tracksvary throughout recordings. The machine learning algorithms may include,for example, a neural network, a Markov model, or a dynamic Bayesiannetwork.

As described herein, the machine learning algorithms may be trained topredict the metadata of the upcoming fragment of music when providedwith the metadata of music up to that point. Music generator module 160may use implement the predictive algorithm by searching a pool ofprerecorded audio files for those with properties that most closelymatch the metadata predicted to come next. Selecting the closestmatching audio file to play next helps create output music content withsequential progression of music properties similar to the examplerecordings that the predictive algorithm was trained on.

In some embodiments, parametric control of music generator module 160using predictive algorithms may be included in the predictive algorithmitself. In such embodiments, some predefined parameter may be usedalongside musical metadata as an input to the algorithm and predictionsvary based on this parameter. Alternatively, parametric control may beapplied to the predictions to modify them. As one example, bysequentially selecting the closest music fragment predicted to come nextby the predictive algorithm and appending the audio of the files end toend, a generative composition is made. At some point, a listener mayincrease a control element level (such as an onsets-per-beat controlelement) and the output of the predictive model is modified byincreasing the predicted ‘onsets-per-beat’ data-field. When selectingthe next audio file to append to the composition, those with higheronset-per-beat properties will be more likely to be selected in thisscenario.

In various embodiments, generative systems, such as music generatormodule 160, utilizing metadata descriptions of music content may usehundreds or thousands of data-fields in the metadata for each musicfragment. To give more variability, multiple concurrent tracks, eachfeaturing different instrument and sound types may be used. In theseinstances, the predictive model may have many thousands of data-fieldsrepresenting music properties, with each having a perceptible effect onthe listening experience. For a listener to control the music in suchinstances, an interface for modifying each data-field of the predictivemodel's output may be used, creating thousands of control elements.Alternatively, multiple data-fields may be combined and exposed as asingle control element. As more music properties are affected by asingle control element, the more abstract the control element becomesfrom the specific music properties, and labelling of these controlsbecomes subjective. In this way primary control elements andsub-parameter control elements (as described below) may be implementedfor dynamic and individualized control of output music content 140.

As described herein, users may specify their own control elements andtrain music generator module 160 regarding how to act based on useradjustment of the control element. This process may reduce bias andcomplexity, and the data-fields may be completely hidden from thelistener. For example, in some embodiments the listener is provided witha user-created control element on the user interface. The listener isthen presented with a short music clip, for which they are asked to seta level of the control element they believe best describes the musicbeing heard. By repeating this process, multiple data points are createdthat may be used to regressively model the desired effect of the controlon the music. In some embodiments, these data points may be added as anadditional input in the predictive model. The predictive model may thentry to predict the music properties that will produce a compositionsequence similar to sequences it has been trained on while also matchingthe expected behavior of a control element being set to a particularlevel. Alternatively, a control element mapper, in the form of aregression model, may be used to map prediction modifiers to the controlelement without retraining the predictive model.

In some embodiments, training for a given control element may includeboth global training (e.g., training based on feedback from multipleuser accounts) and local training (e.g., training based on feedback fromthe current user's account). In some embodiments, a set of controlelements may be created that are specific to a subset of the musicalelements provided by a composer. For instance, a scenario may include anartist creating a loop pack and then training music generator module 160using examples of performances or compositions they have previouslycreated using these loops. Patterns in these examples can be modelledwith regression or neural network models and used to create rules forthe construction of new music with similar patterns. These rules may beparametrized and exposed as control elements for the composer tomanually modify offline, before the listener begins using musicgenerator module 160, or for the listener to adjust while listening.Examples that the composer feels are opposite to the desired effect ofthe control may also be used for negative reinforcement.

In some embodiments, in addition to utilizing patterns in the examplemusic, music generator module 160 may find patterns in music it createsthat correspond to input from a composer, before the listener beginslistening to the generated music. The composer may do this with directfeedback (described below) such as tapping a thumbs up control elementfor positive reinforcement of patterns or thumbs down control elementfor negative reinforcement.

In various embodiments, music generator module 160 may allow a composerto create their own sub-parameter control elements, described below, ofcontrol elements the music generator module has learned. For example, acontrol element for “intensity” may have been created as a primarycontrol element from learned patterns relating to the number of noteonsets per beat and the textural qualities of the instruments playing.The composer may then create two sub-parameter control elements byselecting patterns that relate to note onsets, such as a “rhythmicintensity” control element and a “textural intensity” control elementfor the textural patterns. Examples of sub-parameter control elementsinclude control elements for vocals, intensity of a particular frequencyrange (e.g., bass), complexity, tempo, etc. These sub-parameter controlelements may be used in conjunction with more abstract control elements(e.g., primary control elements) such as energy. These composer skillcontrol elements may be trained for music generator module 160 by thecomposer similarly to user-created controls described herein.

As described herein, training of music generator module 160 to controlaudio parameters based on input from a user-created control elementallows individual control elements to be implemented for differentusers. For example, one user may associate increased attitude withincreased bass content while another user may associate increasedattitude with a certain type of vocals or a certain tempo range. Musicgenerator module 160 may modify audio parameters for the differentspecifications of attitude based on the training of the music generatormodule for a specific user. In some embodiments, individualized controlsmay be used in combination with global rules or control elements thatare implemented in the same way for many users. The combination ofglobal and local feedback or control may provide quality musicproduction with specialized controls for involved individuals.

In various embodiments, as shown in FIG. 8, one or more UI controlelements 830 are implemented in UI module 820. As described above, auser may adjust control element level(s) 832 using control element(s)830 during interaction with UI module 820 to modify output music content140. In certain embodiments, one or more of control element(s) 830 is asystem-defined control element. For instance, a control element may bedefined as a controllable parameter by system 800. In such embodiments,a user may adjust the system-defined control element to modify outputmusic content 140 according to parameters defined by the system.

In certain embodiments, a system-defined UI control element (e.g., aknob or slider) allows users to control abstract parameters of outputmusic content 140 being automatically generated by music generatormodule 160. In various embodiments, the abstract parameters act asprimary control element inputs. Examples of abstract parameters include,but are not limited to, intensity, complexity, mood, genre, and energylevel. In some embodiments, an intensity control element may adjust thenumber of low-frequency loops incorporated. A complexity control elementmay guide the number of tracks overlayed. Other control elements such asa mood control element may range from sober to happy and affect, forexample, the key of music being played, among other attributes.

In various embodiments, a system-defined UI control element (e.g., aknob or slider) allows users to control energy level of output musiccontent 140 being automatically generated by music generator module 160.In some embodiments, the label of the control element (e.g., “energy”)may change in size, color, or other properties to reflect user inputadjusting the energy level. In some embodiments, as the user adjusts thecontrol element, the control element's current level may be output untilthe user releases the control element (e.g., releases a mouse click orremoves a finger from a touchscreen).

Energy, as defined by the system, may be an abstract parameter relatedto multiple more specific music attributes. As an example, energy may berelated to tempo in various embodiments. For instance, changes in energylevel may be associated with tempo changes of a selected number of beatsper minute (e.g., ˜6 beats per minute). In some embodiments, within agiven range for one parameter (such as tempo), music generator module160 may explore music variations by changing other parameters. Forexample, music generator module 160 may create build-ups and drops,create tension, vary the number of tracks being layered at the sametime, change keys, add or remove vocals, add or remove bass, playdifferent melodies, etc.

In some embodiments, one or more sub-parameter control elements areimplemented as control element(s) 830. Sub-parameter control elementsmay allow more specific control of attributes that are incorporated intoa primary control element such as an energy control element. Forexample, the energy control element may modify the number of percussivelayers and amount of vocals used, but a separate control element allowsfor direct control of these sub-parameters such that all controlelements are not necessarily independent. In this way, the user canchoose the level of specificity of control they wish to utilize. In someembodiments, sub-parameter control elements may be implemented foruser-created control elements, described above. For example, a user maycreate and label a control element that specifies a sub-parameter ofanother user-specified parameter.

In some embodiments, user interface module 820 allows a user an optionto expand a UI control element 830 to show one or more sub-parameteruser control elements. Additionally, certain artists may provideattribute information that is used to guide music composition underneathuser control of a high-level control element (e.g., an energy slider).For instance, an artist may provide an “artist pack” with tracks fromthat artist and rules for music composition. The artist may use anartist interface to provide values for sub-parameter user controlelements. For example, a DJ might have rhythm and drums as a controlelement that is exposed to the user to allow the listener to incorporatemore or less rhythm and drums. In some embodiments, as described herein,artists or users may generate their own custom control elements.

In various embodiments, human-in-the-loop generative systems may be usedto generate artifacts with the aid of human intervention and control topotentially increase quality and fit of generated music for individualpurpose. For some embodiments of music generator module 160, thelistener may become a listener-composer by controlling generativeprocesses through the interface control elements 830 implemented in UImodule 820. The design and implementation of these control elements mayaffect the balance between listener and composer roles for anindividual. For example, highly detailed and technical control elementsmay reduce the influence of generative algorithms and put more creativecontrol in the hands of a user while requiring more hands-on interactionand technical skill to manage.

To the contrary, higher-level control elements may reduce the requiredeffort and time of interaction while reducing creative control. Forexample, for individuals that desire a more listener-type role, primarycontrol elements, as described herein, may be favorable. Primary controlelements may be based, for example, on abstract parameters such as mood,intensity or genre. These abstract parameters of music may be subjectivemeasures that are often interpreted individually. For instance, in manycases, the listening environment has an effect on how listeners describemusic. Thus, music that a listener might call ‘relaxing’ at a party maybe too energetic and tense for a meditation session.

In some embodiments, one or more UI control element(s) 830 areimplemented to receive user feedback on output music content 140. Userfeedback control elements may include, for example, a star rating, athumbs up/thumbs down, etc. In various embodiments, the user feedbackmay be used to train the system to a user's particular taste and/or moreglobal tastes that are applied for multiple users. In embodiments withthumbs up/thumbs down (e.g., positive/negative) feedback, the feedbackis binary. Binary feedback with that include strong positive and strongnegative responses may be effective in providing positive and negativereinforcement for the function of control element(s) 830. In somecontemplated embodiments, input from thumbs up/thumbs down controlelements can be used to control output music content 140 (e.g., thethumbs up/thumbs down control elements are used to control outputthemselves). For instance, a thumbs up control element can be used tomodify the maximum repetitions of the currently playing output musiccontent 140.

In some embodiments, a counter for each audio file keeps track of howmany times a section (e.g., an 8 beat segment) of that audio file hasbeen played recently. Once a file has been used above a desiredthreshold value a bias may be applied against its selection. This biasmay gradually return to zero over-time. Together with rule-defined musicsections that set the desired function of the music (e.g., buildup,drop, breakdown, intro, sustain), this repetition counter and bias maybe used to shape music into segments with coherent themes. For example,music generator module 160 may increase the counter on a thumbs downpress such that the audio content of output music content 140 isencouraged to change sooner without disrupting the musical function ofthe section. Similarly, music generator module 160 may decrease thecounter on a thumbs up press such that the audio content of output musiccontent 140 is not biased away from repetition for a longer period.Before the threshold is reached and bias applied, other machine learningand rule-based mechanisms in music generator module 160 may still leadto selection of other audio content.

In some embodiments, music generator module 160 is configured todetermine various contextual information (e.g., environment information150, shown in FIG. 1) around the time that user feedback is received.For example, in conjunction with receiving a “thumbs up” indication froma user, music generator module 160 may determine the time of day,location, device velocity, biometric data (e.g., heart rate), etc. fromenvironment information 150. In some embodiments, this contextualinformation may be used to train a machine learning model to generatemusic that the user prefers in various different contexts (e.g., themachine learning model is context aware).

In various embodiments, music generator module 160 determines thecurrent type of environment and takes different actions for the sameuser adjustment in different environments. For example, music generatormodule 160 may take environmental measurements and listener biometricswhen the listener trains an “attitude” control element. During thetraining, music generator module 160 is trained to include thesemeasures as part of the control element. In this example, when thelistener is doing a high intensity work-out at the gym the “attitude”control element may affect the intensity of the drum beat. When sittingat a computer, changing the “attitude” control element may not affectdrum beat but may increase distortion of bass lines. In suchembodiments, a single user control element may have different sets ofrules or differently-trained machine learning models that are used,alone or in combination, differently in different listeningenvironments.

In contrast to contextual awareness, if an expected behavior of acontrol element is static, it may be likely that a number of controlscan become necessary or desired for every listening context musicgenerator module 160 is used in. Thus, in some embodiments, thedisclosed techniques may provide functionality for multiple environmentswith a single control element. Implementing a single control element formultiple environments may reduce the number of control elements, makingthe user interface simpler and more quickly searched. In someembodiments, control element behavior is made dynamic. Dynamism for acontrol element may come from utilizing measurements of the environment,such as: sound levels recorded by microphones, heart-rate measurements,time of day and rate of movement, etc. These measurements may be used asadditional inputs to the control element training. Thus, the samelistener interaction with a control element will have potentiallydifferent musical effects depending on the environmental context inwhich the interaction occurs.

In some embodiments, the contextual awareness functionality describedabove is different from the concept of a generative music systemchanging generative processes based on environmental context. Forexample, these techniques may modify the effects of user controlelements based on environmental context, which may be used alone or incombination with the concept of generating music based on environmentalcontext and outputs of user controls.

In some embodiments, music generator module 160 is configured to controlgenerated output music content 140 to achieve a stated goal. Examples ofstated goals include, but are not limited to, sales goals, biometricgoals such as heart rate or blood pressure, and ambient noise goals.Music generator module 160 may learn how to modify manually(user-created) or algorithmically (system-defined) produced controlelements using techniques described herein to generate output musiccontent 140 in order to meet a stated goal.

Goal states may be measurable environment and listener states that alistener wants to achieve while, and with the aid of, listening to musicwith music generator module 160. These goal states may be influenceddirectly—through music modifying the acoustic experience of the spacethe listener is in, or may be mediated through psychological effects,such as certain music encouraging focus. As one example, the listenermay set a goal to have a lower heart-rate during a run. By recording theheart rate of the listener under different states of the availablecontrol elements, music generator module 160 has learned that thelistener's heart rate typically reduces when a control element named“attitude” is set to a low level. Thus, to help the listener achieve alow heart rate, music generator module 160 may automate the “attitude”control to a low level.

By creating the kind of music that the listener expects in a specificenvironment, music generator module 160 may help create the specificenvironment. Examples include heart-rate, overall volume of sound in thelistener's physical space, sales in a store, etc. Some environmentalsensors and state data may not be suitable for goal states. Time of day,for example, may be an environment measure that is used as input forachieving a goal state of inducing sleep, but music generator module 160cannot control the time of day itself.

In various embodiments, while sensor inputs may be disconnected from thecontrol element mapper while trying to reach a state goal, the sensorsmay continue to record and instead provide a measure for comparing theactual with the target goal state. A difference between the target andactual environmental states may be formulated as a reward function for amachine learning algorithm that may adjust the mappings in the controlelement mapper while in a mode trying to achieve the goal state. Thealgorithm may adjust mappings to reduce the difference between thetarget and actual environmental states.

While there are many physiological and psychological effects of musiccontent, creating music content the listener expects in a specificenvironment may not always help create that environment for thelistener. In some instances, no effect or a negative effect towardsmeeting the target state may occur. In some embodiments, music generatormodule 160 may adjust music properties based on past results whilebranching in other directions if changes are not meeting a threshold.For example, if reducing the “attitude” control element did not resultin a lower heart-rate for the listener, music generator module 160 maytransition and develop new strategies using other control elements orgenerate a new control element using the actual state of the targetvariable as positive or negative reinforcement for a regression orneural network model.

In some embodiments, if context is found to affect the expected behaviorof a control element for a specific listener, it may imply that thedata-points (e.g., audio parameters) being modified by the controlelement in some specific context is related to the context for thatlistener. As such, these data-points may provide a good initial pointfor trying to generate music that produces an environmental change. Forexample, if a listener always manually turns up a “rhythmic” controlelement when the listener goes to the train station, then musicgenerator module 160 may begin to automatically increase this controlelement when it detects the listener is at the train station.

In some embodiments, as described herein, music generator module 160 istrained to implement control elements that match a user's expectations.If music generator module 160 is trained from end-to-end for eachcontrol element (e.g., from control element level to output musiccontent 140), the complexity of a training for each control element maybe high, which may make training slower. Further, establishing the idealcombinatorial effects of multiple control elements may be difficult. Foreach control element, however, music generator module 160 should ideallybe trained to perform an expected musical change based on the controlelement. For example, music generator module 160 may be trained for an“energy” control element by a listener to make the rhythmic densityincrease as “energy” is increased. Because the listener is exposed tothe final output music content 140 and not just individual layers of themusic content, music generator module 160 may be trained to affect thefinal output music content using the control element. This may, however,become a multi-step problem such as, for a specific control setting, themusic should sound like X, and to create music that sounds like X, theset of audio files Y should be used on each track.

In certain embodiments, a teacher/student framework is adopted toaddress the above-described issues. FIG. 10 is a block diagramillustrating an exemplary teacher/student framework system, according tosome embodiments. In the illustrated embodiment, system 1000 includesteacher model implementation module 1010 and student modelimplementation module 1020.

In certain embodiments, teacher model implementation module 1010implements a trained teacher model. For instance, a trained teachermodel may be a model that learns how to predict how a final mix (e.g., astereo mix) should sound without any consideration of the set of loopsavailable in the final mix. In some embodiments, a learning process fora teacher model utilizes real-time analysis of output music content 140using a fast Fourier transform (FFT) to calculate the distribution ofsound across different frequencies for sequences of short time steps.The teacher model may search for patterns in these sequences utilizing atime sequence prediction model such as a recurrent neural network (RNN).In some embodiments, the teacher model in teacher model implementationmodule 1010 may be trained offline on stereo recordings for whichindividual loops or audio files are not available.

In the illustrated embodiment, teacher model implementation module 1010receives output music content 140 and generates compact description 1012of the output music content. Using the trained teacher model, teachermodel implementation module 1010 may generate compact description 1012without any consideration of the audio tracks or audio files in outputmusic content 140. Compact description 1012 may include a description,X, of what output music content 140 should sound like as determined byteacher model implementation module 1010. Compact description 1012 ismore compact than output music content 140 itself.

Compact description 1012 may be provided to student model implementationmodule 1020. Student model implementation module 1020 implements atrained student model. For instance, a trained student model may be amodel that learns how to produce music that matches a compactdescription using audio files or loops, Y (which is different than X).In the illustrated embodiment, student model implementation module 1020generates student output music content 1014 that substantially matchesoutput music content 140. As used here, the phrase “substantiallymatches” indicates that student output music content 1014 sounds similarto output music content 140. For example, a trained listener mayconsider that student output music content 1014 and output music content140 sound the same.

In many instances, control elements may be expected to affect similarpatterns in music. For example, a control element may affect both pitchrelationships and rhythm. In some embodiments, music generator module160 is trained for a large number of control elements according to oneteacher model. By training music generator module 160 for a large numberof control elements with a single teacher model, similar basic patternsmay not need to be relearned for each control element. In suchembodiments, student models of the teacher model then learn how to varythe selection of loops for each track to achieve the desired attributesin the final music mix. In some embodiments, properties of the loops maybe pre-calculated to reduce the learning challenge and baselineperformance (though it may be at the expense of potentially reducing thelikelihood of finding an optimal mapping of a control element).

Non-limiting examples of music attributes pre-calculated for each loopor audio file that may be used for student model training includes thefollowing: ratio of bass to treble frequencies, number of note onsetsper second, ratio of pitched to unpitched sounds detected, spectralrange, average onset intensity. In some embodiments, a student model isa simple regression model that is trained to select loops for each trackto get the closest music properties in the final stereo mix. In variousembodiments, the student/teacher model framework may have someadvantages. For example, if new properties are added to thepre-calculation routine for loops, there is no need to retrain the wholeend-to-end model, just the student models.

As another example, as properties of the final stereo mix that affectdifferent controls are likely common to other control elements, trainingmusic generator module 160 for each control element as an end-to-endmodel would mean each model needs to learn the same thing (stereo mixmusic features) to get to the best loop selection, making trainingslower and harder than it may need to be. Only the stereo output needsto be analyzed in real-time and as the output music content is generatedin real-time for the listener, music generator module 160 may get thesignal for “free” computationally. Even the FFT may be already appliedfor visualization and audio mixing purposes. In this way, the teachermodel may be trained to predict the combined behavior of controlelements and music generator module 160 is trained to find ways ofadapting to other control elements while still producing the desiredoutput music content. This may encourage training for control elementsto emphasize unique effects of a particular control element and reducecontrol elements having effects that diminish the impact of othercontrol elements.

Exemplary Low Resolution Pitch Detection System

Pitch detection that is robust to polyphonic music content and diverseinstrument types may traditionally be difficult to achieve. Tools thatimplement end-to-end music transcription may take an audio recording andattempt to produce a written score, or symbolic music representation inthe form of MIDI. Without knowledge of beat placement or tempo, thesetools may need to infer musical rhythmic structure, instrumentation, andpitch. The results may vary, with common problems being detecting toomany short, nonexistent notes in the audio file and detecting harmonicsof a note as the fundamental pitch.

Pitch detection may also be useful, however, in situations whereend-to-end transcription is not needed. For making harmonically sensiblecombinations of music loops, for example, it may be sufficient to knowwhich pitches are audible on each beat without needing to know the exactplacement of a note. If the length and tempo of the loop are known, thetemporal position of beats may not need to be inferred from the audio.

In some embodiments, a pitch detection system is configured to detectwhich fundamental pitches (e.g., C, C# . . . B) are present in shortmusic audio files of known beat length. By reducing the problem scopeand focusing on robustness to instrument texture, high-accuracy resultsmay be achieved for beat resolution pitch detection.

In some embodiments, the pitch detection system is trained on exampleswhere the ground truth is known. In some embodiments, the audio data iscreated from score data. MIDI and other symbolic music formats may besynthesized using software audio synthesizers with random parameters fortexture and effects. For each audio file, the system may generate a logspectrogram 2D representation with multiple frequency bins for eachpitch class. This 2D representation is used as input to a neural networkor other AI technique where a number of convolutional layers are used tocreate a feature representation of the frequency and time representationof the audio. Convolution stride and padding may be varied dependent onaudio file length to produce a constant model output shape withdifferent tempo input. In some embodiments, the pitch detection systemappends recurrent layers to the convolutional layers to output atemporally dependent sequence of predictions. A categorical crossentropy loss may be used to compare the logic output of the neuralnetwork with a binary representation of the score.

The design of convolutional layers combined with recurrent layers may besimilar to work in speech to text, with modifications. For example,speech to text typically needs to be sensitive to relative pitch changebut not absolute pitch. Thus, the frequency range and resolution istypically small. Further, text may need to be invariant to speed in away that is not desirable in static-tempo music. Connectionist temporalclassification (CTC) loss computation often utilized in speech-to-texttasks may not be needed, for example, because the length of outputsequences is known in advance, which reduces complexity for training.

The following representation has 12 pitch classes for each beat, with 1representing the presence of that fundamental note in the score used tosynthesize the audio. (C, C# . . . B) and each row representing a beat,e.g., with later rows representing scores at different beats:

0 1 0 0 1 0 0 0 1 0 0 1 0 0 0 0 0 0 0 0 1 0 0 1 0 0 0 0 0 0 0 0 1 0 0 10 0 0 0 0 0 0 0 1 0 0 1 0 0 0 0 0 0 1 0 1 0 0 0 0 0 0 0 0 0 1 0 1 0 0 00 0 0 0 0 0 0 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1

In some embodiments, the neural network is trained on classical musicand pseudo random generated music scores of 1-4 parts (or more) harmonyand polyphony. The data augmentation may help with robustness to musiccontent with filters and effects such as reverb, which can be a point ofdifficulty for pitch detection (e.g., because part of the fundamentaltone lingers after the original note has ended). In some embodiments,the dataset may be biased and loss weightings are used as it is muchmore likely for a pitch class to not have a note played on each beat.

In some embodiments, the format of output allows for harmonic clashes tobe avoided on each beat while maximizing the range of harmonic contextsthat a loop can be used in. For example, a bass loop could comprise onlyan F and move down to an E on the last beat of a loop. This loop willlikely sound harmonically acceptable for most people in the key of F. Ifno temporal resolution is provided, and it is only known that an E andan F are in the audio, then it could be a sustained E with a short F atthe end, which would not sound acceptable for most people in the contextof the key of F. With higher resolution, the chance of harmonics,fretboard sound, and slides being detected as individual notes increasesand thus additional notes could be falsely identified. By developing thesystem with the optimal resolution of temporal and pitch information forcombining short audio recordings of instruments to create a musical mixwith harmonically sound combinations, the complexity of the pitchdetection problem may be reduced and robustness to short, lesssignificant pitch events is increased, according to some embodiments.

In various embodiments of the music generator system described herein,the system may allow listeners to select the audio content that is usedto create a pool from which the system constructs (generates) new music.This approach may be different from creating a playlist as the user doesnot need to select individual tracks or organize selectionssequentially. Additionally, content from multiple artists may be usedtogether simultaneously. In some embodiments, music content is groupedinto “Packs” that are designed by software providers or by contributingartists. A Pack contains multiple audio files with corresponding imagefeatures and feature metadata files. A single Pack may contain, forexample, 20 to 100 audio files that are available for use by the musicgenerator system to create music. In some embodiments, a single Pack maybe selected or multiple Packs may be selected in combination. Duringplayback, Packs may be added or removed without stopping the music.

Exemplary Audio Techniques for Music Content Generation

In various embodiments, software frameworks for managing real-timegenerated audio may benefit from supporting certain types offunctionality. For instance, audio processing software may follow amodular signal chain metaphor inherited from analog hardware, wheredifferent modules providing for audio generation and audio effects arechained together into an audio signal graph. Individual modules willtypically expose various continuous parameters allowing for real-timemodification of the module's signal processing. In the early days ofelectronic music, the parameters were often themselves analog signals,and thus the parameter processing chain and the signal processing chaincoincided. Since the digital revolution, parameters have tended to be aseparate digital signal.

Embodiments disclosed herein recognize that, for real-time musicgeneration systems—whether a system interacts live with human performersor the system implements machine learning or other artificialintelligence (AI) techniques to generate music—a flexible control systemthat allows coordination and combination of parameters manipulations maybe advantageous. Additionally, the present disclosure recognizes that itmay also be advantageous for the effects of parameter changes to beinvariant to changes in tempo.

In some embodiments, a music generator system generates new musiccontent from playback music content based on different parameterrepresentations of an audio signal. For example, an audio signal can berepresented by both a graph of the signal (e.g., an audio signal graph)relative to time and a graph of the signal relative to beats (e.g., asignal graph). The signal graph is invariant to tempo, which allows fortempo invariant modification of audio parameters of the music content inaddition to tempo variant modifications based on the audio signal graph.

FIG. 11 is a block diagram illustrating an exemplary system configuredto implement audio techniques in music content generation, according tosome embodiments. In the illustrated embodiment, system 1100 includesgraph generation module 1110 and audio technique music generator module1120. Audio technique music generator module 1120 may operate as a musicgenerator module (e.g., the audio technique music generator module ismusic generator module 160, described herein) or the audio techniquemusic generator module may be implemented as a part of a music generatormodule (e.g., as part of music generator module 160).

In the illustrated embodiment, music content 1112, which includes audiofile data, is accessed by graph generation module 1110. Graph generationmodule 1110 may generate first graph 1114 and second graph 1116 for anaudio signal in the accessed music content 1112. In certain embodiments,first graph 1114 is an audio signal graph that graphs an audio signal asa function of time. The audio signal may include, for example,amplitude, frequency, or a combination of both. In certain embodiments,second graph 1116 is a signal graph that graphs the audio signal as afunction of beats.

In certain embodiments, as shown in the illustrated embodiment of FIG.11, graph generation module 1110 is located in system 1100 to generatefirst graph 1114 and second graph 1116. In such embodiments, graphgeneration module 1110 may be collocated with audio technique musicgenerator module 1120. Other embodiments are contemplated, however,where graph generation module 1110 is located in a separate system andaudio technique music generator module 1120 accesses the graphs from theseparate system. For instance, the graphs may be generated and stored ona cloud-based server that is accessible by audio technique musicgenerator module 1120.

FIG. 12 depicts an example of an audio signal graph (e.g., first graph1114). FIG. 13 depicts an example of a signal graph (e.g., second graph1116). In the illustrated graphs in FIGS. 12 and 13, each change in theaudio signal is represented as a node (e.g., audio signal node 1202 inFIG. 12 and signal node 1302 in FIG. 13). Thus, the parameters of aspecified node determine (e.g., define) the changes to the audio signalat the specified node. As first graph 1114 and second graph 1116 arebased on the same audio signal, the graphs may have similar structurewith variant between the graphs being the x-axis scale (time versusbeats). Having similar structure in the graphs allows modification ofparameters (described below) for a node in one graph (e.g., node 1302 insecond graph 1116) that corresponds to a node in the other graph (e.g.,node 1202 in first graph 1114) to be determined by parameters eitherdownstream or upstream of the node in the one graph.

Turning back to FIG. 11, first graph 1114 and second graph 1116 arereceived (or accessed) by audio technique music generator module 1120.In certain embodiments, audio technique music generator module 1120generates new music content 1122 from playback music content 1118 basedon audio modifier parameters selected from first graph 1114 and audiomodifier parameters selected from second 1116. For instance, audiotechnique music generator module 1120 may modify playback music content1118 with audio modifier parameters from either first graph 1114, audiomodifier parameters from second graph 1116, or a combination thereof.New music content 1122 is generated by the modification of playbackmusic content 1118 based on the audio modifier parameters.

In various embodiments, audio technique music generator module 1120 mayselect the audio modifier parameters to implement in the modification ofplayback content 1118 based on whether a tempo variant modification, atempo invariant modification, or a combination thereof is desired. Forinstance, a tempo variant modification may be made based on audiomodifier parameters selected or determined from first graph 1114 while atempo invariant modification may be made based on audio modifierparameters selected or determined from second graph 1116. In embodimentswhere a combination of tempo variant modification and tempo invariantmodification is desired, audio modifier parameters may be selected fromboth first graph 1114 and second graph 1116. In some embodiments, theaudio modifier parameters from each individual graph are separatelyapplied to different properties (e.g., amplitude or frequency) ordifferent layers (e.g., different instrumental layers) in playback musiccontent 1118. In some embodiments, the audio modifier parameters fromeach graph are combined into a single audio modifier parameter to applyto a single property or layer in playback music content 1118.

FIG. 14 depicts an exemplary system for implementing real-timemodification of music content using audio technique music generatormodule 1420, according to some embodiments. In the illustratedembodiment, audio technique music generator module 1420 includes firstnode determination module 1410, second node determination module 1420,audio parameter determination module 1430, and audio parametermodification module 1440. Together, first node determination module1410, second node determination module 1420, audio parameterdetermination module 1430, and audio parameter modification module 1440implement system 1400.

In the illustrated embodiment, audio technique music generator module1420 receives playback music content 1418 that includes an audio signal.Audio technique music generator module 1420 may process the audio signalthrough first graph 1414 (e.g., the time-based audio signal graph) andsecond graph 1416 (e.g., the beat-based signal graph) in first nodedetermination module 1410. As the audio signal goes through first graph1414, the parameters for each node in the graph determine the changes tothe audio signal. In the illustrated embodiment, second nodedetermination module 1420 may receive information on first node 1412 anddetermine information for second node 1422. In certain embodiments,second node determination module 1420 reads the parameters in secondgraph 1416 based on a location of the first node found in first nodeinformation 1412 in the audio signal going through first graph 1414.Thus, as an example, the audio signal going to node 1202 in first graph1414 (shown in FIG. 12) as determined by first node determination module1410 may trigger second node determination module 1420 determining thecorresponding (parallel) node 1302 in second graph 1416 (shown in FIG.13).

As shown in FIG. 14, audio parameter determination module 1430 mayreceive second node information 1422 and determine (e.g., select)specified audio parameters 1432 based on the second node information.For instance, audio parameter determination module 1430 may select audioparameters based on a portion of the next beats (e.g., x number of nextbeats) in second graph 1416 that follow a location of the second node asidentified in second node information 1422. In some embodiments, a beatto real-time conversion may be implemented to determine the portion ofsecond graph 1416 from which audio parameters may be read. The specifiedaudio parameters 1432 may be provided to audio parameter modificationmodule 1440.

Audio parameter modification module 1440 may control the modification ofmusic content to generate new music content. For instance, audioparameter modification module 1440 may modify playback music content1418 to generate new music content 1122. In certain embodiments, audioparameter modification module 1440 modifies properties of playback musiccontent 1418 by modifying specified audio parameters 1432 (as determinedby audio parameter determination module 1430) for an audio signal in theplayback music content. For example, modifying specified audioparameters 1432 for the audio signal in playback music content 1418modifies properties such as amplitude, frequency, or a combination ofboth in the audio signal. In various embodiments, audio parametermodification module 1440 modifies properties of different audio signalsin playback music content 1418. For instance, different audio signals inplayback music content 1418 may correspond to different instrumentsrepresented in playback music content 1418.

In some embodiments, audio parameter modification module 1440 modifiesproperties of audio signals in playback music content 1418 using machinelearning algorithms or other AI techniques. In some embodiments, audioparameter modification module 1440 modifies properties of playback musiccontent 1418 according to user input to the module, which may beprovided through a user interface associated with the music generationsystem. Embodiments may also be contemplated where audio parametermodification module 1440 modifies properties of playback music content1418 using a combination of AI techniques and user input. The variousembodiments for modification of the properties of playback music content1418 by audio parameter modification module 1440 allow real-timemanipulation of music content (e.g., manipulation during playback). Asdescribed above, the real-time manipulation can include applying a tempovariant modification, a tempo invariant combination, or a combination ofboth to audio signals in playback music content 1418.

In some embodiments, audio technique music generator module 1420implements a 2-tiered parameter system for modification of theproperties of playback music content 1418 by audio parametermodification module 1440. In the 2-tiered parameter system, there may bea differentiation between “automations” (e.g., tasks performedautomatically by the music generation system), which directly controlaudio parameter values, and “modulations”, which layer audio parametermodifications on top of the automations multiplicatively, as describedbelow. The 2-tiered parameter system may allow different parts of themusic generation system (e.g., different machine learning models in thesystem architecture) to separately consider different musical aspects.For instance, one part of a music generation system may set the volumeof a particular instrument according to intended section type of thecomposition, whereas another part may overlay a periodic variation ofthe volume for added interest.

Exemplary Techniques for Real-Time Audio Effects in Music ContentGeneration

Music technology software typically allows composers/producers tocontrol various abstract envelopes via automations. In some embodiments,automations are pre-programmed temporal manipulations of some audioprocessing parameter (such as volume, or reverb amount). Automations aretypically either manually defined break-point envelopes (e.g., piecewiselinear functions) or programmatic functions such as sinewaves (otherwiseknown as low frequency oscillators (LFOs)).

The disclosed music generator system may be different from typical musicsoftware. For instance, most parameters are, in a sense, automated bydefault. AI techniques in the music generator system may control most orall audio parameters in various ways. At a base level, a neural networkmay predict appropriate settings for each audio parameter based on itstraining. It may, however, be helpful to provide the music generatorsystem with some higher-level automation rules. For example, large-scalemusical structures may dictate a slow build in volume as an extraconsideration, on top of the low-level settings that might otherwise bepredicted.

The present disclosure generally relates to information architecture andprocedural approaches for combining multiple parametric imperativessimultaneously issued by different levels of a hierarchical generativesystem to create a musically coherent and varied continuous output. Thedisclosed music generator system may create long-form musicalexperiences that are intended to be experienced continuously for severalhours. Long-form musical experiences need to create a coherent musicaljourney for a more satisfactory experience. To do this, the musicgenerator system may reference itself over long timescales. Thesereferences may vary from direct to abstract.

In certain embodiments, to facilitate larger scale musical rules, themusic generator system (e.g., music generator module 160) exposes anautomation API (application programming interface). FIG. 15 depicts ablock diagram of an exemplary API module in a system for automation ofaudio parameters, according to some embodiments. In the illustratedembodiment, system 1500 includes API module 1505. In certainembodiments, API module 1505 includes automation module 1510. The musicgenerator system may support both wavetable-style LFOs and arbitrarybreakpoint envelopes. Automation module 1510 may apply automation 1512to any audio parameter 1520. In some embodiments, automation 1512 isapplied recursively. For example, any programmatic automation like asinewave, which itself has parameters (frequency, amplitude, etc.), canhave automation applied to those parameters.

In various embodiments, automations 1512 include a signal graph parallelto the audio signal graph, as described above. The signal graph may behandled similarly: via a “pull” technique. In the “pull” technique, APImodule 1505 may request automation module 1510 to recalculate as needed,and to do the recalculation such that an automation 1512 recursivelyrequests the upstream automations on which it depends to do the same. Incertain embodiments, the signal graph for the automation is updated at acontrolled rate. For example, the signal graph may update once each runof the performance engine update routine, which may align with theblock-rate of the audio (e.g., after the audio signal graph renders oneblock (one block is, for instance, 512 samples)).

In some embodiments, it may be desirable for audio parameters 1520themselves to vary at an audio-sample rate, otherwise discontinuousparameter changes at audio-block boundaries can lead to audibleartefacts. In certain embodiments, the music generator system managesthis issue by treating an automation update as a parameter value target.When the real-time audio thread renders an audio-block, the audio threadwill smoothly ramp a given parameter from its current value to thesupplied target value over the course of the block.

A music generator system described herein (e.g., music generator module160, shown in FIG. 1) may have an architecture with a hierarchicalnature. In some embodiments, different parts of the hierarchy mayprovide multiple suggestions for the value of a particular audioparameter. In certain embodiments, the music generator system providestwo separate mechanisms for combining/resolving multiple suggestions:modulation and overriding. In the illustrated embodiment of FIG. 15,modulation 1532 is implemented by modulation module 1530 and override1542 is implemented by overriding module 1540.

In some embodiments, an automation 1512 can be declared to be amodulation 1532. Such a declaration may mean that rather than setting anaudio parameter's value directly, the automation 1512 should actmultiplicatively on the audio parameter's current value. Thus,large-scale musical sections can apply a long modulation 1532 to anaudio parameter (for example, a slow crescendo for a volume fader) andthe value of the modulation will multiply whatever value other parts ofthe music generator system might dictate.

In various embodiments, API module 1505 includes overriding module 1540.Overriding module 1540 may be, for example, an override facility foraudio parameter automation. Overriding module 1540 may be intended to beused by external control interfaces (e.g., an artist control userinterface). Overriding module 1540 may take control over an audioparameter 1520 regardless of what the music generator system tries to dowith it. When an audio parameter 1520 is overridden by override 1542,the music generator system may create a “Shadow Parameter” 1522 thattracks where the audio parameter would be if it wasn't overridden (e.g.,where the audio parameter would be based on automation 1512 ormodulation 1532). Thus, when the override 1542 is “released” (e.g.,removed by the artist), the audio parameter 1520 can snap back to whereit would have been according to automation 1512 or modulation 1532.

In various embodiments, these two approaches can be combined. Forexample, an override 1542 can be a modulation 1532. When override 1542is modulation 1532, the basic value of an audio parameter 1520 may stillbe set by the music generator system but then multiplicatively modulatedby the override 1542 (which overrides any other modulation). Each audioparameter 1520 may have one (or zero) automation 1512 and one (or zero)modulation 1532 at the same time, as well as one (or zero) of eachoverride 1542.

In various embodiments, an abstract class hierarchy is defined asfollows (note there is some multiple inheritance):

-   -   Automatable        -   AutomationParameter        -   Parameter            -   AudioNodeParameter            -   MacroParameter            -   ShadowParameter    -   Beat-Dependent        -   Automation            -   Envelope            -   ParameterFollower            -   Periodic            -   TransformedAutomation            -   UberAutomation            -   MacroParameter            -   ShadowParameter

Based on the abstract class hierarchy, things may be considered aseither Automations, or Automatable. In some embodiments, any automationmay be applied to anything that is automatable. Automations includethings like LFOs, Break-point envelopes, etc. These automations are alltempo-locked, which means that they change through time according to thecurrent beat.

Automations may themselves have automatable parameters. For example, thefrequency and amplitude of an LFO automation are automatable. Thus,there is a signal graph of dependent automations and automationparameters running in parallel to the audio signal graph but at acontrol-rate rather than an audio rate. As described above, the signalgraph uses a pull-model. The music generator system keeps track of anyautomations 1512 applied to audio parameters 1520, and updates theseonce per “game loop”. The automations 1512 in turn request updates oftheir own automated audio parameters 1520 recursively. This recursiveupdate logic may reside in a base class Beat-Dependent, which expects tobe called frequently (but not necessarily regularly). The update logicmay have a prototype described as follows:

-   -   BeatDependent::update(double currentBeat, int updateCounter,        bool overRider)

In certain embodiments, the BeatDependent class maintains a list of itsown dependencies (e.g., other BeatDependent instances), and recursivelycalls their update functions. An updateCounter may be passed up thechain such that the signal graph can have cycles without doubleupdating. This may be important because automations may be applied toseveral different automatables. In some embodiments, this may not matterbecause the second update will have the same currentBeat as the first,and these update routines should be impotent unless the beat changes.

In various embodiments, when an automation is applied to an automatable,each cycle of the “game loop”, the music generator system may request anupdated value from each automation (recursively), and use that to setthe value of the automatable. In this instance, “set” may depend on theparticular subclass, and also on whether the parameter is also beingmodulated and/or overridden.

In certain embodiments, a modulation 1532 is an automation 1512 that isapplied multiplicatively, rather than absolutely. For instance, amodulation 1532 can be applied to an already automated audio parameter1520, and its effect will be as a percentage of the automated value.This multiplicatively may allow, for example, ongoing oscillationsaround a moving mean.

In some embodiments, audio parameters 1520 can be overridden, meaning,as described above, that any automations 1512 or modulations 1532applied to them, or other (less privileged) requests are overridden bythe overriding value in override 1542. This overriding may allowexternal control over some aspects of the music generator system, whilstmusic generator system continues as it otherwise would. When audioparameter 1520 is overridden, the music generator system keeps track ofwhat the value would be (e.g., keeps track of the appliedautomations/modulations and other requests). When the override isreleased, the music generator system snaps the parameter to where itwould have been.

To facilitate modulations 1532 and overrides 1542, the music generatorsystem may abstract a setValue method of a Parameter. There may also bea private method _setValue, which actually sets the value. An example ofa public method is as follows:

void Parameter::setValue(float value, bool overRider) {  _unmodulated->setValue(value, overRider);  if (!modulated( ))  _setValue(value, overRider); }

The public method may reference a member variable of the Parameter classcalled unmodulated. This variable is an instance of ShadowParameter,described above. Every audio parameter 1520 has a shadow parameter 1522that tracks where it would be if not modulated. If an audio parameter1520 is not currently being modulated, both the audio parameter 1520 andits shadow parameter 1522 are updated with the requested value.Otherwise, the shadow parameter 1522 tracks the request, and the actualaudio parameter value 1520 is set elsewhere (e.g., in anupdateModulations routine—where the modulating factor is multiplied bythe shadow parameter value to give the actual parameter value).

In various embodiments, large scale structure in long-form musicalexperiences is be achieved by various mechanisms. One broad approach maybe the use of musical self-references over time. For example, a verydirect self-reference would be exactly repeating some audio segmentpreviously played. In music theory, the repeated segment may be called atheme (or a motif). More typically, music content usestheme-and-variation, whereby the theme is repeated at a later time withsome variation to give a sense of coherence but maintain a sense ofprogress. The music generator system disclosed herein may usetheme-and-variation to create large-scale structure in several ways,including direct repetition or through the use of abstract envelopes.

An abstract envelope is a value of an audio parameter through time.Abstracted from the audio parameter it is controlling, an abstractenvelope may be applied to any other audio parameter. For example, acollection of audio parameters could be automated in concert by a singlecontrolling abstract envelope. This technique may “bond” differentlayers together perceptually for a short term. Abstract envelopes mayalso be reused temporally and applied to different audio parameters. Inthis way, the abstract envelope becomes the abstract musical theme, andthis theme is repeated by applying the envelope to a different audioparameter later in the listening experience. Thus, there is a variationon the theme while a sense of structure and long-term coherence isestablished.

Viewed as musical themes, abstract envelopes can abstract many musicalfeatures. Examples of musical features that may be abstracted include,but are not limited to:

-   -   Building in tension (volume of any track, level of distortion,        etc.).    -   Rhythm (volume adjustment and/or gating creates rhythmic effect        applied to pads, etc.).    -   Melody (pitch filtering can imitate melodic contours applied to        pads, etc.).

Exemplary Additional Audio Techniques for Real-Time Music ContentGeneration

Real-time music content generation may present unique challenges. Forexample, because of a hard real-time constraint, function calls orsubroutines that have unpredictable and potentially unbounded executiontimes should be avoided. Avoiding this issue may rule out the use ofmost high-level programming languages, and large parts of low-levellanguages such as C and C++. Anything that allocates memory from theheap (e.g., via a malloc under the hood) may be ruled out as well asanything that may potentially block, such as locking a mutex. This maymake multithreaded programming particularly difficult for real-timemusic content generation. Most standard memory management approaches mayalso not be viable, and consequently dynamic data structures such as C++STL containers have limited use for real-time music content generation.

Another area of challenge may be the management of audio parametersinvolved in DSP (digital signal processing) functions (such as thecutoff frequency for a filter). For instance, when changing audioparameters dynamically, audible artefacts may occur unless the audioparameters are changed continuously. Thus, communication between thereal-time DSP audio thread(s) and user-facing or programmatic interfacesmay be needed to change the audio parameters.

Various audio software may be implemented to deal with theseconstraints, and various approaches exist. For example:

-   -   Interthread communication may be handled with lock-free message        queues.    -   Functions may be written in plain C and utilize function pointer        callbacks.    -   Memory management may be implemented via custom “zones” or        “arenas”    -   “Two-speed” system may be implemented with real-time audio        thread calculations running at audio-rate, and control audio        thread running at “control-rate”. The control audio thread may        set audio parameter change goals, which the real-time audio        thread smoothly ramps to.

In some embodiments, synchronizing between control-rate audio parametermanipulation and the real-time audio thread safe storage of audioparameter values for use in actual DSP routines may require some sort ofthread-safe communication of audio parameter goals. Most audioparameters for audio routines are continuous (rather than discrete) andthus are typically represented by floating point data types. Variouscontortions to the data have been historically necessitated by the lackof a lock-free atomic floating point data type.

In certain embodiments, a simple lock-free atomic floating point datatype is implemented in the music generator system described herein. Alock-free atomic floating point data type may be achieved by treatingthe floating-point type as a sequence of bits, and “tricking” thecompiler into treating it as an atomic integer type of the samebit-width. This approach may support atomic getting/setting, which issuitable for the music generator system described herein. An exampleimplementation of a lock-free atomic floating point data type isdescribed as follows:

// atomic float class af32 { public: af32( ) { } af32(float x) {operator( )(x); } ~af32( ) { } af32(const af32& x) : valueStore(x( )) {} af32& operator=(const af32& x) { this->operator( )(x( )); return*this; } float operator( )( ) const { uint32_t voodoo =atomic_load(&valueStore); return ((float )&voodoo); } void operator()(float value) { uint32_t voodoo = ((uint32_t )&value);atomic_store(&_valueStore, voodoo); } private:std::atomic_uint32_t_valueStore { 0 }; };

In some embodiments, dynamic memory allocations from the heap are notviable for real-time code associated with music content generation. Forexample, static stack-based allocations may make it difficult to useprogramming techniques such as dynamic storage containers and functionalprogramming approaches. In certain embodiments, the music generatorsystem described herein implements “memory zones” for memory managementin real-time contexts. As used herein, a “memory zone” is an area ofheap allocated memory that is allocated up-front without real-timeconstraints (e.g., when real-time constraints are not yet present orpaused). Memory storage objects may then be created in the area of heapallocated memory without needing to request more memory from the system,thereby making the memory real-time safe. Garbage collection may includedeallocating the memory zone as a whole. The memory implementation bythe music generator system may also be multithreading safe, real-timesafe, and efficient.

FIG. 16 depicts a block diagram of an exemplary memory zone 1600,according to some embodiments. In the illustrated embodiment, memoryzone 1600 includes heap allocated memory module 1610. In variousembodiments, heap allocated memory module 1610 receives and stores firstgraph 1114 (e.g., the audio signal graph), second graph 1116 (e.g., thesignal graph), and audio signal data 1602. Each of the stored items maybe retrieved, for example, by audio parameter modification module 1440(shown in FIG. 14).

An example implementation of a memory zone is described as follows:

// memory poolclass MemoryZone { public: MemoryZone(uint64_t sz) :sz(sz), zone((char)malloc(sz)) { } ~MemoryZone( ) { free(zone); } void*bags(size_t obj_size, size_t alignment) { uint64_t p = atomic_load(&p);uint64_t q = p % uint64_t(alignment); if (p + q > sz) return nullptr;uint64_t pp = atomic_fetch_add(&p, uint64_t(obj_size) + q); if (pp == p){ return zone_ + p + q; } else { return bags(obj_size, alignment); } }uint64_t used( ) {return atomic_load(&p); } uint64_t available( ) {return int64_t(sz) − int64_t(atomic_load(&p)); } void hose( ) {atomic_store(&p, 0ULL); } private: char zone; uint64_t sz;std::atomic_uint64_t p_ { 0 }; };

In some embodiments, different audio threads of the music generatorsystem need to communicate with each other. Typical thread-safetyapproaches (which may include locking ‘mutually exclusive’ datastructures) may not be usable in a real-time context. In certainembodiments, dynamic routing data serializations to a pool ofsingle-producer single-consumer circular buffers are implemented. Acircular buffer is a type of FIFO (first-in first-out) queue datastructure that typically doesn't require dynamic memory allocation afterinitialization. A single-producer, single-consumer thread safe circularbuffer may allow one audio thread to push data into the queue whileanother audio thread pulls data out. For the music generator systemdescribed herein, circular buffers may be extended to allowmultiple-producer, single-consumer audio threads. These buffers may beimplemented by pre-allocating a static array of circular buffers anddynamically routing serialized data to a particular “channel” (e.g., aparticular circular buffer) according to an identifier added to musiccontent produced by the music generator system. The static array ofcircular buffers may be accessible by a single user (e.g., thesingle-consumer).

FIG. 17 depicts a block diagram of an exemplary system for storing newmusic content, according to some embodiments. In the illustratedembodiment, system 1700 includes circular buffer static array module1710. Circular buffer static array module 1710 may include a pluralityof circular buffers that allow storage of multiple-producer,single-consumer audio threads according to thread identifiers. Forexample, circular buffer static array module 1710 may receive new musiccontent 1122 and store the new music content for access by a user in1712.

In various embodiments, abstract data structures, such as dynamiccontainers (vector, queue, list), are typically implemented innon-real-time-safe ways. These abstract data structures may, however, beuseful for audio programming. In certain embodiments, the musicgenerator system described herein implements a custom list datastructure (e.g., singly linked-list). Many functional programmingtechniques may be implemented from the custom list data structure. Thecustom list data structure implementation may use the “memory zones”(described above) for underlying memory management. In some embodiments,the custom list data structure is serializable, which may make it safefor real-time use and able to be communicated between audio threadsusing the multiple-producer, single-consumer audio threads describedabove.

Exemplary Blockchain Ledger Techniques

Disclosed systems may utilize secure recording techniques such asblockchains or other cryptographic ledgers, in some embodiments, torecord information about generated music or elements thereof such asloops or tracks. In some embodiments, a system combines multiple audiofiles (e.g., tracks or loops) to generate output music content. Thecombination may be performed by combining multiple layers of audiocontent such that they overlap at least partially in time. The outputcontent may be discrete pieces of music or may be continuous. Trackinguse of musical elements may be challenging in the context of continuousmusic, e.g., in order to provide royalties to relevant stakeholders.Therefore, in some embodiments, disclosed systems record an identifierand usage information (e.g., timestamps or the number of plays) foraudio files used in composed music content. Further, disclosed systemsmay utilize various algorithms for tracking playback times in thecontext of blended audio files, for example.

As used herein, the term “blockchain” refers to a set of records(referred to as blocks) that are cryptographically linked. For example,each block may include a cryptographic hash of the previous block, atimestamp, and transaction data. A blockchain may be used as a publicdistributed ledger and may be managed by a network of computing devicesthat use an agreed-upon protocol for communication and validating newblocks. Some blockchain implementations may be immutable while othersmay allow subsequent alteration of blocks. Generally, blockchains mayrecord transactions in a verifiable and permanent fashion. Whileblockchain ledgers are discussed herein for purposes of illustration, itis to be understood that the disclosed techniques may be used with othertypes of cryptographic ledgers in other embodiments.

FIG. 18 is a diagram illustrating example playback data, according tosome embodiments. In the illustrated embodiment, a database structureincludes entries for multiple files. Each illustrated entry includes afile identifier, a start timestamp, and a total time. The fileidentifier may uniquely identify audio files tracked by the system. Thestart timestamp may indicate the first inclusion of the audio file inmixed audio content. This timestamp may be based on a local clock of aplayback device or based on an internet clock, for example. The totaltime may indicate the length of the interval over which the audio filewas incorporated. Note that this may be different than the length of theaudio file, e.g., if only a portion of the audio file is used, if theaudio file is sped up or slowed down in the mix, etc. In someembodiments, when an audio file is incorporated at multiple differenttimes, each time results in an entry. In other embodiments, additionalplays for a file may result in an increase to the time field of anexisting entry, if an entry already exists for the file. In still otherembodiments, the data structure may track the number of times each audiofile is used rather than the length of incorporation. Further, otherencodings of time-based usage data are contemplated.

In various embodiments, different devices may determine, store, and usea ledger to record playback data. Example scenarios and topologies arediscussed below with reference to FIG. 19. Playback data may betemporarily stored on a computing device before being committed to aledger. Stored playback data may be encrypted, e.g., to reduce or avoidmanipulation of entries or insertion of false entries.

FIG. 19 is a block diagram illustrating an example composition system,according to some embodiments. In the illustrated example, the systemincludes playback device 1910, computing system 1920, and ledger 1930.

Playback device 1910, in the illustrated embodiment, receives controlsignaling from computing system 1920 and sends playback data tocomputing system 1920. In this embodiment, playback device 1910 includesplayback data recording module 1912, which may record playback databased on audio mixes played by playback device 1910. Playback device1910 also includes playback data storage module 1914, which isconfigured to store playback data temporarily, in a ledger, or both.Playback device 1910 may periodically report playback data to computingsystem 1920 or may report playback data in real time. Playback data maybe stored for later reporting when playback device 1910 is offline, forexample.

Computing system 1920, in the illustrated embodiment, receives playbackdata and commits entries that reflect the playback data to ledger 1930.Computing system 1920 also sends control signaling to the playbackdevice 1910. This control signaling may include various types ofinformation in different embodiments. For example, the control signalingmay include configuration data, mixing parameters, audio samples,machine learning updates, etc. for use by playback device 1910 tocompose music content. In other embodiments, computing system 1920 maycompose music content and stream the music content data to playbackdevice 1910 via the control signaling. In these embodiments, modules1912 and 1914 may be included in computing system 1920. Speakinggenerally, the modules and functionality discussed with reference toFIG. 19 may be distributed among multiple devices according to varioustopologies.

In some embodiments, playback device 1910 is configured to commitentries directly to ledger 1930. For example, a playback device such asa mobile phone may compose music content, determine the playback data,and store the playback data. In this scenario, the mobile device mayreport the playback data to a server such as computing system 1920 ordirectly to a computing system (or set of computing nodes) thatmaintains ledger 1930.

In some embodiments, the system maintains a record of rights holders,e.g., with mappings to audio file identifiers or to sets of audio files.This record of entities may be maintained in the ledger 1930 or in aseparate ledger or some other data structure. This may allow rightsholders to remain anonymous, e.g., when the ledger 1930 is public butincludes a non-identifying entity identifier that is mapped to an entityin some other data structure.

In some embodiments, music composition algorithms may generate a newaudio file from two or more existing audio files for inclusion in a mix.For example, the system may generate new audio file C based on two audiofiles A and B. One technique for such blending uses interpolationbetween vector representations of the audio of files A and B andgenerating file C using an inverse transformation from vector to audiorepresentation. In this example, the play time for audio files A and Bmay both be incremented, but they may be incremented by less than theiractual play time, e.g., because they were blended.

For example, if audio file C is incorporated into mixed content for 20seconds, audio file A may have playback data that indicates 15 secondand audio file B may have playback data that indicates 5 seconds (andnote that the sum of the blended audio files may or may not match thelength of use of the resulting file C). In some embodiments, theplayback time for each original file is based on its similarly to theblended file C. For example, in vector embodiments, for an n-dimensionalvector representation, the interpolated vector a has the followingdistance d from the vector representations of audio files A and B:

d(a,c)=((a1−c1)²+(a2−c2)²+ . . . +(an−cn)²)^(1/2)

d(b,c)=((b1−c1)²+(b2−c2)²+ . . . +(bn−cn)²)^(1/2)

In these embodiments, the playback time i for each original file may bedetermined as:

${{i(a)} = {t*\frac{d\left( {a,c} \right)}{{d\left( {b,c} \right)} + {d\left( {a,c} \right)}}}}{{i(b)} = {t*\frac{d\left( {b,c} \right)}{{d\left( {b,c} \right)} + {d\left( {a,c} \right)}}}}$

where t represents the playback time of file C.

In some embodiments, forms of remuneration may be incorporated into theledger structure. For example, certain entities may include informationassociating audio files with performance requirements such as displayinga link or including an advertisement. In these embodiments, thecomposition system may provide proof of performance of the associatedoperation (e.g., displaying an advertisement) when including an audiofile in a mix. The proof of performance may be reported according to oneof various appropriate reporting templates that require certain fieldsto show how and when the operation was performed. The proof ofperformance may include time information and utilize cryptography toavoid false assertions of performance. In these embodiments, use of anaudio file that does not also show proof of performance of theassociated required operation may require some other form ofremuneration such as a royalty payment. Generally, different entitiesthat submit audio files may register for different forms ofremuneration.

As discussed above, disclosed techniques may provide trustworthy recordsof audio file use in music mixes, even when composed in real-time. Thepublic nature of the ledger may provide confidence in fairness ofremuneration. This may in turn encourage involvement of artists andother collaborators, which may improve the variety and quality of audiofiles available for automated mixing.

In some embodiments, an artist pack may be made with elements that areused by the music engine to create continuous soundscapes. Artist packsmay be professionally (or otherwise) curated sets of elements that arestored in one or more data structures associated with an entity such asan artist or group. Examples of these elements include, withoutlimitation, loops, composition rules, heuristics, and neural netvectors. Loops may be included in a database of music phrases. Each loopis typically a single instrument or sets of related instruments playinga musical progression over a period of time. These can range from shortloops (e.g. 4 bars) to longer loops (e.g. 32 to 64 bars) and so on.Loops may be organized into layers such as melody, harmony, drums, bass,tops, FX etc. A loop database may also be represented as a VariationalAuto Encoder with encoded loop representations. In this case, loopsthemselves are not needed, rather a NN is used to generate sounds thatare encoded in the NN.

Heuristics refers to parameters, rules, or data that guide the musicengine is the creation of music. Parameters guide such elements assection length, use of effects, frequency of variational techniques,complexity of music, or generally speaking any type of parameter thatcould be used to augment the music engines decision making as itcomposes and renders music.

The ledger records transactions related to consumption of content thathas rights holders associated with it. This could be loops, heuristics,or neural network vectors, for example. The goal of the ledger is torecord these transactions and make them inspectable for transparentaccounting. The ledger is meant to capture transactions as they happen,which may include consumption of content, use of parameters in guidingthe music engine, and use of vectors on a neural network, etc. Theledger may record various transaction types including discrete events(e.g. this loop was played at this time), this pack was played for thisamount of time, or this machine learning module (e.g., neural networkmodule) was used for this amount of time.

The ledger makes it possible to associate multiple rights holders withany given artist pack or, more granularly, with specific loops or otherelements of the artist pack. For example, a label, artist, and composermight have rights for a given artist pack. The ledger may allow them toassociate payment details for the pack which specifics what percentageeach of party will receive. For example, the artist could receive 25%,the label 25% and the composer 50%. Use of blockchain to manage thesetransactions may allow micro-payments to be made in real-time to each ofthe rights holder, or accumulated over appropriate time periods.

As indicated above, in some implementations, loops might be replacedwith VAEs that are essentially encodings of the loops in a machinelearning module. In this case, the ledger may associate playtime with aparticular artist pack that includes the machine learning module. Forexample, if an artist pack is played on aggregate 10% of the total playtime across all devices, then this artist could receive 10% of the totalrevenue distribution.

In some embodiments, the system allows artists to create artistprofiles. The profiles include pertinent information for the artistincluding bio, profile picture, banking details, and other data neededto verify the artist identity. Once an artist profile is created, theartist can then upload and publish artist packs. These packs includeelements that are used by the music engine to create soundscapes.

For each artist pack that is created, rights holders can be defined andassociated with the pack. Each rights holder can claim a percentage ofthe pack. In addition, each rights holder creates a profile andassociates a bank account with their profile for payment. Artists arethemselves rights holders and may own 100% of the rights associated withtheir packs.

In addition to recording events in the ledger that will be used forrevenue recognition, the ledger may manage promotions that areassociated with an artist pack. For example, an artist pack might have afree month promotion where the revenue generated will be different thanwhen the promo is not running. The ledger automatically accounts forthese revenue inputs as it calculates the payments to the rightsholders.

This same model for rights management may allow an artist to sell rightsto their pack to one or more external rights holders. For example, atthe launch of a new pack, an artist could pre-fund their pack by selling50% of their stake in the pack to fans or investors. The number ofinvestors/rights-holders in this case could be arbitrarily large. As anexample, the artist could sell 50% of their percentage to 100K users,which of whom would get 1/100K of the revenue generated by the pack.Since all the accounting is managed by the ledger, investors would bepaid directly in this scenario, removing any need for auditing of artistaccounts.

Exemplary User and Enterprise GUIs

FIGS. 20A-20B are block diagrams illustrating graphical user interfaces,according to some embodiments. In the illustrated embodiment, FIG. 20Acontains a GUI displayed by user application 2010 and FIG. 20B containsa GUI displayed by enterprise application 2030. In some embodiments, theGUIs displayed in FIGS. 20A and 20B are generated by a website ratherthan by an application. In various embodiments, any of variousappropriate elements may be displayed, including one or more of thefollowing elements: dials (e.g., to control volume, energy, etc.),buttons, knobs, display boxes (e.g., to provide the user with updatedinformation), etc.

In FIG. 20A, user application 2010 displays a GUI that contains section2012 for selecting one or more artist packs. In some embodiments, packs2014 may alternatively or additionally include theme packs or packs fora specific occasion (e.g., a wedding, birthday party, graduationceremony, etc.). In some embodiments, the number of packs shown insection 2012 is greater than the number that can be displayed in section2012 at one time. Therefore, in some embodiments, the user scrolls upand/or down in section 2012 to view one or more packs 2014. In someembodiments, the user can select an artist pack 2014 based on whichhe/she would like to hear output music content. In some embodiments,artist packs may be purchased and/or downloaded, for example.

Selection element 2016, in the illustrated embodiment, allows the userto adjust one or more music attributes (e.g., energy level). In someembodiments, selection element 2016 allows the user to add/delete/modifyone or more target music attributes. In various embodiments, selectionelement 2016 may render one or more UI control elements (e.g., controlelements 830).

Selection element 2020, in the illustrated embodiment, allows the userto let the device (e.g., mobile device) listen to the environment todetermine target musical attributes. In some embodiments, the devicecollects information about the environment using one or more sensors(e.g., cameras, microphones, thermometers, etc.) after the user selectsselection element 2020. In some embodiments, application 2010 alsoselects or suggests one or more artist packs based on the environmentinformation collected by the application when the user selected element2020.

Selection element 2022, in the illustrated embodiment, allows the userto combine multiple artist packs to generate a new rule set. In someembodiments, the new rule set is based on the user selecting one or morepacks for the same artist. In other embodiments, the new rule set isbased on the user selecting one or more packs for different artists. Theuser may indicate weights for different rule sets, e.g., such that ahighly-weighted rule set has more effect on generated music than alower-weighted rule set. The music generator may combine rule sets inmultiple different ways, e.g., by switching between rules from differentrule sets, averaging values for rules from multiple different rule sets,etc.

In the illustrated embodiment, selection element 2024 allows the user toadjust rule(s) in one or more rule sets manually. For example, in someembodiments, the user would like to adjust the music content beinggenerated at a more granular level, by adjusting one or more rules inthe rule set used to generate the music content. In some embodiments,this allows the user of application 2010 to be their own disk jockey(DJ), by using the controls displayed in the GUI in FIG. 20A to adjust arule set used by a music generator to generate output music content.These embodiments may also allow more fine-grained control of targetmusic attributes.

In FIG. 20B, enterprise application 2030 displays a GUI that alsocontains an artist pack selection section 2012 with artist packs 2014.In the illustrated embodiment, the enterprise GUI displayed byapplication 2030 also contains element 2016 to adjust/add/delete one ormore music attributes. In some embodiments, the GUI displayed in FIG.20B is used in a business or storefront to generate a certainenvironment (e.g., for optimizing sales) by generating music content. Insome embodiments, an employee uses application 2030 to select one ormore artist packs that have been previously shown to increase sales (forexample, metadata for a given rule set may indicate actual experimentalresults using the rule set in real-world contexts).

Input hardware 2040, in the illustrated embodiment, sends information tothe application or website that is displaying enterprise application2030. In some embodiments, input hardware 2040 is one of the following:a cash register, heat sensors, light sensors, a clock, noise sensors,etc. In some embodiments, the information sent from one or more of thehardware devices listed above is used to adjust target music attributesand/or a rule set for generating output music content for a specificenvironment. In the illustrated embodiment, selection element 2038allows the user of application 2030 to select one or more hardwaredevices from which to receive environment input.

Display 2034, in the illustrated embodiment, displays environment datato the user of application 2030 based on information from input hardware2040. In the illustrated embodiment, display 2032 shows changes to arule set based on environment data. Display 2032, in some embodiments,allows the user of application 2030 to see the changes made based on theenvironment data.

In some embodiments, the elements shown in FIGS. 20A and 20B are fortheme packs and/or occasion packs. That is, in some embodiments, theuser or business using the GUIs displayed by applications 2010 and 2030can select/adjust/modify rule sets to generate music content for one ormore occasions and/or themes.

Detailed Example Music Generator System

FIGS. 21-23 show details regarding specific embodiments of musicgenerator module 160. Note that although these specific examples aredisclosed for purposes of illustration, they are not intended to limitthe scope of the present disclosure. In these embodiments, constructionof music from loops is performed by a client system, such as a personalcomputer, mobile device, media device, etc. As used in the discussion ofFIGS. 21-23, the term “loops” may be interchangeable with the term“audio files”. In general, loops are included in audio files, asdescribed herein. Loops may be divided into professionally curated looppacks, which may be referred to as artist packs. Loops may be analyzedfor music properties and the properties may be stored as loop metadata.Audio in constructed tracks may be analyzed (e.g., in real-time) andfiltered to mix and master the output stream. Various feedback may besent to the server, including explicit feedback such as from userinteraction with sliders or buttons and implicit feedback, e.g.,generated by sensors, based on volume changes, based on listeninglengths, environment information, etc. In some embodiments, controlinputs have known effects (e.g., to specify target music attributesdirectly or indirectly) and are used by the composition module.

The following discussion introduces various terms used with reference toFIGS. 21-23. In some embodiments, a loop library is a master library ofloops, which may be stored by a server. Each loop may include audio dataand metadata that describes the audio data. In some embodiments, a looppackage is a subset of the loop library. A loop package may be a packfor a particular artist, for a particular mood, for a particular type ofevent, etc. Client devices may download loop packs for offline listeningor download parts of loop packs on demand, e.g., for online listening.

A generated stream, in some embodiments, is data that specifies themusic content that the user hears when they use the music generatorsystem. Note that the actual output audio signals may vary slightly fora given generated stream, e.g., based on capabilities of audio outputequipment.

A composition module, in some embodiments, constructs compositions fromloops available in a loop package. The composition module may receiveloops, loop metadata, and user input as parameters and may be executedby a client device. In some embodiments, the composition module outputsa performance script that is sent to a performance module and one ormore machine learning engines. The performance script, in someembodiments, outlines which loops will be played on each track of thegenerated stream and what effects will be applied to the stream. Theperformance script may utilize beat-relative timing to represent whenevents occur. The performance script may also encode effect parameters(e.g., for effects such as reverb, delay, compression, equalization,etc.).

A performance module, in some embodiments, receives a performance scriptas input and renders it into a generated stream. The performance modulemay produce a number of tracks specified by the performance script andmix the tracks into a stream (e.g., a stereo stream, although the streammay have various encodings including surround encodings, object-basedaudio encodings, multi-channel stereo, etc. in various embodiments). Insome embodiments, when provided with a particular performance script,the performance module will always produce the same output.

An analytics module, in some embodiments, is a server-implemented modulethat receives feedback information and configures the composition module(e.g., in real-time, periodically, based on administrator commands,etc.). In some embodiments, the analytics module uses a combination ofmachine learning techniques to correlate user feedback with performancescripts and loop library metadata.

FIG. 21 is a block diagram illustrating an example music generatorsystem that includes analysis and composition modules, according to someembodiments. In some embodiments, the system of FIG. 21 is configured togenerate a potentially-infinite stream of music with direct user controlover the mood and style of music. In the illustrated embodiment, thesystem includes analysis module 2110, composition module 2120,performance module 2130, and audio output device 2140. In someembodiments, analysis module 2110 is implemented by a server andcomposition module 2120 and performance module 2130 are implemented byone or more client devices. In other embodiments, modules 2110, 2120,and 2130 may all be implemented on a client device or may all beimplemented server-side.

Analysis module 2110, in the illustrated embodiment, stores one or moreartist packs 2112 and implements a feature extraction module 2114, aclient simulator module 2116, and a deep neural network 2118.

In some embodiments, feature extraction module 2114 adds loops to a looplibrary after analyzing loop audio (although note that some loops may bereceived with metadata already generated and may not require analysis).For example, raw audio in a format such as way, aiff, or FLAC may beanalyzed for quantifiable musical properties such as instrumentclassification, pitch transcription, beat timings, tempo, file length,and audio amplitude in multiple frequency bins. Analysis module 2110 mayalso store more abstract musical properties or mood descriptions forloops, e.g., based on manual tagging by artists or machine listening.For example, moods may be quantified using multiple discrete categories,with ranges of values for each category for a given loop.

Consider, for example, a loop A that is analyzed to determine that thenotes G2, Bb2, and D2 are used, the first beat begins 6 millisecondsinto the file, the tempo is 122 bpm, the file is 6483 milliseconds long,and the loop has normalized amplitude values of 0.3, 0.5, 0.7, 0.3, and0.2 across five frequency bins. The artist may label the loop as “funkgenre” with the following mood values:

Transcendence Peacefulness Power Joy Sadness Tension HIGH HIGH LOWMEDIUM NONE LOW

Analysis module 2110 may store this information in a database andclients may download subsections of the information, e.g., as looppackages. Although artists packs 2112 are shown for purposes ofillustration, analysis module 2110 may provide various types of looppackages to composition module 2120.

Client simulator module 2116, in the illustrated embodiment, analyzesvarious types of feedback to provide feedback information in a formatsupported by deep neural network 2118. In the illustrated embodiment,the deep neural network 2118 also receives performance scripts generatedby composition modules as inputs. In some embodiments, the deep neuralnetwork configures the composition module based on these inputs, e.g.,to improve correlations between types of generated music output anddesired feedback. For example, the deep neural network may periodicallypush updates to client devices implementing composition module 2120.Note that deep neural network 2118 is shown for purposes of illustrationand may provide strong machine learning performance in disclosedembodiments, but is not intended to limit the scope of the presentdisclosure. In various embodiments, various types of machine learningtechniques may be implemented alone or in various combinations toperform similar functionality. Note that machine learning modules may beused to implement rule sets (e.g., arrangement rules or techniques)directly in some embodiments or may be used to control modulesimplementing other types of rule sets, e.g., using deep neural network2118 in the illustrated embodiment.

In some embodiments, analysis module 2110 generates compositionparameters for composition module 2120 to improve correlation betweendesired feedback and use of certain parameters. For example, actual userfeedback may be used to adjust composition parameters, e.g., to attemptto reduce negative feedback.

As one example, consider a situation where module 2110 discovers acorrelation between negative feedback (e.g., explicit low rankings, lowvolume listening, short listening times, etc.) and compositions that usea high number of layers. In some embodiments, module 2110 uses atechnique such as backpropagation to determine that adjustingprobability parameters used to add more tracks reduces the frequency ofthis issue. For example, module 2110 may predict that reducing aprobability parameter by 50% will reduce negative feedback by 8% and maydetermine to perform the reduction and push updated parameters to thecomposition module (note that probability parameters are discussed indetail below, but any of various parameters for statistical models maysimilarly be adjusted).

As another example, consider a situation where module 2110 discoversthat negative feedback is correlated with the user setting mood controlto high tension. A correlation between loops with low tension tags andusers asking for high tension may also be found. In this case, module2110 may increase a parameter such that the probability of selectingloops with high tension tags is increased when users ask for hightension music. Thus, the machine learning may be based on variousinformation, including composition outputs, feedback information, usercontrol inputs, etc.

Composition module 2120, in the illustrated embodiment, includes asection sequencer 2122, section arranger 2124, technique implementationmodule 2126, and loop selection module 2128. In some embodiments,composition module 2120 organizes and constructs sections of thecomposition based on loop metadata and user control input (e.g., moodcontrol).

Section sequencer 2122, in some embodiments, sequences different typesof sections. In some embodiments, section sequencer 2122 implements afinite state machine to continuously output the next type of sectionduring operation. For example, composition module 2120 may be configuredto use different types of sections such as an intro, buildup, drop,breakdown, and bridge, as discussed in further detail below withreference to FIG. 23. Further, each section may include multiplesubsections that define how the music changes throughout a section,e.g., including a transition-in subsection, a main content subsection,and a transition-out subsection.

Section arranger 2124, in some embodiments, constructs subsectionsaccording to arranging rules. For example, one rule may specify totransition-in by gradually adding tracks. Another rule may specify totransition-in by gradually increasing gain on a set of tracks. Anotherrule may specify to chop a vocal loop to create a melody. In someembodiments, the probability of a loop in the loop library beingappended to a track is a function of the current position in a sectionor subsection, loops that overlap in time on another track, and userinput parameters such as a mood variable (which may be used to determinetarget attributes for generated music content). The function may beadjusted, e.g., by adjusting coefficients based on machine learning.

Technique implementation module 2120, in some embodiments, is configuredto facilitate section arrangement by adding rules, e.g., as specified byan artist or determined by analyzing compositions of a particularartist. A “technique” may describe how a particular artist implementsarrangement rules at a technical level. For example, for an arrangementrule that specifies to transition-in by gradually adding tracks, onetechnique may indicate to add tracks in order of drums, bass, pads, thenvocals while another technique may indicate to add tracks in order ofbass, pads, vocals, then drums. Similarly, for an arrangement rule thatspecifies to chop a vocal loop to create a melody a technique mayindicate to chop vocals on every second beat and repeat a choppedsection of loop twice before moving to the next chopped section.

Loop selection module 2128, in the illustrated embodiment, selects loopsaccording to the arrangement rules and techniques, for inclusion in asection by section arranger 2124. Once sections are complete,corresponding performance scripts may be generated and sent toperformance module 2130. Performance module 2130 may receive performancescript portions at various granularities. This may include, for example,an entire performance script for a performance of a certain length, aperformance script for each section, a performance script for eachsub-section, etc. In some embodiments, arrangement rules, techniques, orloop selection are implemented statistically, e.g., with differentapproaches used different percentages of the time.

Performance module 2130, in the illustrated embodiment, includes filtermodule 2131, effect module 2132, mix module 2133, master module 2134,and perform module 2135. In some embodiments, these modules process theperformance script and generate music data in a format supported byaudio output device 2140. The performance script may specify the loopsto be played, when they should be played, what effects should be appliedby module 2132 (e.g., on a per-track or per-subsection basis), whatfilters should be applied by module 2131, etc.

For example, the performance script may specify to apply a low passfilter ramping from 1000 to 20000 Hz from 0 to 5000 milliseconds on aparticular track. As another example, the performance script may specifyto apply reverb with a 0.2 wet setting from 5000 to 15000 millisecondson a particular track.

Mix module 2133, in some embodiments, is configured to perform automatedlevel control for the tracks being combined. In some embodiments, mixmodule 2133 uses frequency domain analysis of the combined tracks tomeasure frequencies with too much or too little energy and applies gainto tracks in different frequency bands to even the mix. Master module2134, in some embodiments, is configured to perform multi-bandcompression, equalization (EQ), or limiting procedures to generate datafor final formatting by perform module 2135. The embodiment of FIG. 21may automatically generate various output music content according touser input or other feedback information, while the machine learningtechniques may allow for improved user experience over time.

FIG. 22 is a diagram illustrating an example buildup section of musiccontent, according to some embodiments. The system of FIG. 21 maycompose such a section by applying arranging rules and techniques. Inthe illustrated example, the buildup section includes three subsectionsand separate tracks for vocals, pad, drum, bass, and white noise.

The transition in subsection, in the illustrated example, includes adrum loop A, which is also repeated for the main content subsection. Thetransition in subsection also includes a bass loop A. As shown, the gainfor the section begins low and increases linearly throughout the section(although non-linear increases or decreases are contemplated). The maincontent and transition-out subsection, in the illustrated example,include various vocal, pad, drum, and bass loops. As described above,disclosed techniques for automatically sequencing sections, arrangingsections, and implementing techniques may generate near-infinite streamsof output music content based on various user-adjustable parameters.

In some embodiments, a computer system displays an interface similar toFIG. 22 and allows artists to specify techniques used to composesections. For example, artists may create structures such as shown inFIG. 22 which may be parsed into code for the composition module.

FIG. 23 is a diagram illustrating example techniques for arrangingsections of music content, according to some embodiments. In theillustrated embodiment, a generated stream 2310 includes multiplesections 2320 that each include a start subsection 2322, developmentsubsection 2324, and transition subsection 2326. In the illustratedexample, multiple types of each section/subsection are show in tablesconnected via dotted lines. The circular elements, in the illustratedembodiment, are examples of arranging tools, which may further beimplemented using specific techniques as discussed below. As shown,various composition decisions may be performed pseudo-randomly accordingto statistical percentages. For example, the types of subsections, thearranging tools for a particular type or subsection, or the techniquesused to implement an arranging tool may be statistically determined.

In the illustrated example, a given section 2320 is one of five types:intro, buildup, drop, breakdown, and bridge, each with differentfunctions that control intensity over the section. The statesub-section, in this example, is one of three types: slow build, suddenshift, or minimal, each with different behavior. The developmentsub-section, in this example, is one of three types, reduce, transform,or augment. The transition sub-section, in this example, is one of threetypes: collapse, ramp, or hint. The different types of sections andsubsections may be selected based on rules or may be pseudo-randomlyselected, for example.

In the illustrated example, the behaviors for different subsection typesare implemented using one or more arranging tools. For a slow build, inthis example, 40% of the time a low pass filter is applied and 80% ofthe time layers are added. For a transform development sub-section, inthis example, 25% of the time loops are chopped. Various additionalarranging tools are shown, including one-shot, dropout beat, applyreverb, add pads, add theme, remove layers, and white noise. Theseexamples are included for purposes of illustration and are not intendedto limit the scope of the present disclosure. Further, to facilitateillustration, these examples may not be complete (e.g., actual arrangingmay typically involve a much larger number of arranging rules).

In some embodiments, one or more arranging tools may be implementedusing specific techniques (which may be artist specified or determinedbased on analysis of an artist's content). For example, one-shot may beimplemented using sound-effects or vocals, loop chopping may beimplemented using stutter or chop-in-half techniques, removing layersmay be implemented by removing synth or removing vocals, white noise maybe implemented using a ramp or pulse function, etc. In some embodiments,the specific technique selected for a given arranging tool may beselected according to a statistical function (e.g., 30% of the timeremoving layers may remove synths and 70% of the time it may removevocals for a given artist). As discussed above, arranging rules ortechniques may be determined automatically by analyzing existingcompositions, e.g., using machine learning.

Example Methods

FIG. 24 is a flow diagram method for using a ledger, according to someembodiments. The method shown in FIG. 24 may be used in conjunction withany of the computer circuitry, systems, devices, elements, or componentsdisclosed herein, among others. In various embodiments, some of themethod elements shown may be performed concurrently, in a differentorder than shown, or may be omitted. Additional method elements may alsobe performed as desired.

At 2410, in the illustrated embodiment, a computing device determinesplayback data that indicates characteristics of playback of a musiccontent mix. The mix may be includes a determined combination ofmultiple audio tracks (note that the combination of tracks may bedetermined in real-time, e.g., just prior to output of the currentportion of the music content mix, which may be a continuous stream ofcontent). The determination may be based on composing the content mix(e.g., by a server or playback device such as a mobile phone) or may bereceived from another device that determines which audio files toinclude in the mix. The playback data may be stored (e.g., in an offlinemode) and may be encrypted. The playback data may be reportedperiodically or in response to certain events (e.g., regainingconnectivity to a server).

At 2420, in the illustrated embodiment, a computing device records, inan electronic block-chain ledger data structure, information specifyingindividual playback data for one or more of the multiple audio tracks inthe music content mix. In the illustrated embodiment, the informationspecifying individual playback data for an individual audio trackincludes usage data for the individual audio track and signatureinformation associated with the individual audio track.

In some embodiments, the signature information is an identifier for oneor more entities. For example, the signature information may be a stringor a unique identifier. In other embodiments, the signature informationmay be encrypted or otherwise obfuscated to avoid others fromidentifying the entit(ies). In some embodiments, the usage data includesat least one of: a time played for the music content mix or a number oftimes played for the music content mix.

In some embodiments, data identifying individual audio tracks in themusic content mix is retrieved from a data store that also indicates anoperation to be performed in association with inclusion of one or moreindividual audio tracks. In these embodiments, the recording may includerecording an indication of proof of performance of the indicatedoperation.

In some embodiments, the system determines, based on informationspecifying individual playback data recorded in the electronicblock-chain ledger, remuneration for a plurality of entities associatedwith the plurality of audio tracks.

In some embodiments, the system determines usage data for a firstindividual audio track that is not included in the music content mix inits original musical form. For example, the audio track may be modified,used to generate a new audio track, etc. and the usage data may beadjusted to reflect this modification or use. In some embodiments, thesystem generates a new audio track based on interpolating between vectorrepresentations of audio in at least two of the multiple audio tracksand the usage data is determined based on a distance between a vectorrepresentation of the first individual audio track and a vectorrepresentation of the new audio track. In some embodiments, the usagedata is based on a ratio of a Euclidean distance from the interpolatedvector representations and vectors in the at least two of the multipleaudio tracks.

FIG. 25 is a flow diagram method for using image representations tocombine audio files, according to some embodiments. The method shown inFIG. 25 may be used in conjunction with any of the computer circuitry,systems, devices, elements, or components disclosed herein, amongothers. In various embodiments, some of the method elements shown may beperformed concurrently, in a different order than shown, or may beomitted. Additional method elements may also be performed as desired.

At 2510, in the illustrated embodiment, a computing device generates aplurality of image representations of a plurality of audio files wherean image representation for a specified audio file is generated based ondata in the specified audio file and a MIDI representation of thespecified audio file). In some embodiments, pixel values in the imagerepresentations represent velocities in the audio files where the imagerepresentations are compressed in resolution of velocity.

In some embodiments, the image representations are two-dimensionalrepresentations of the audio files. In some embodiments, pitch isrepresented by rows in the two-dimensional representations where time isrepresented by columns in the two-dimensional representations and wherepixel values in the two-dimensional representations representvelocities. In some embodiments, pitch is represented by rows in thetwo-dimensional representations where time is represented by columns inthe two-dimensional representations and where pixel values in thetwo-dimensional representations represent velocities. In someembodiments, a pitch axis is banded into two sets of octaves in an 8octave range, where a first 12 rows of pixels represents a first 4octaves with a pixel value of a pixel determining which one of the first4 octaves is represented, and where a second 12 rows of pixelsrepresents a second 4 octaves with the pixel value of the pixeldetermining which one of the second 4 octaves is represented. In someembodiments, odd pixel values along a time axis represent note startsand even pixel values along the time axis represent note sustains. Insome embodiments, each pixel represents a fraction of a beat in atemporal dimension.

At 2520, in the illustrated embodiment, a computing device selectsmultiple ones of the audio files based on the plurality of imagerepresentations.

At 2530, in the illustrated embodiment, a computing device combines themultiple ones of the audio files to generate output music content.

In some embodiments, one or more composition rules are applied to selectthe multiple ones of the audio files based on the plurality of imagerepresentations. In some embodiments, applying one or more compositionrules includes removing pixel values in the image representations abovea first threshold and removing pixel values in the image representationsbelow a second threshold.

In some embodiments, one or more machine learning algorithms are appliedto the image representations for selecting and combining the multipleones of the audio files and generate the output music content. In someembodiments, harmony and rhythm coherence are tested in the output musiccontent.

In some embodiments, a single image representation is generated from theplurality of image representations and a description of texture featuresis appended to the single image representation where the texturefeatures are extracted from the plurality of audio files. In someembodiments, the single image representation is stored along with theplurality of audio files. In some embodiments, multiple ones of theaudio files are selected by applying one or more composition rules onthe single image representation.

FIG. 26 is a flow diagram method for implementing user-created controlelements, according to some embodiments. The method shown in FIG. 26 maybe used in conjunction with any of the computer circuitry, systems,devices, elements, or components disclosed herein, among others. Invarious embodiments, some of the method elements shown may be performedconcurrently, in a different order than shown, or may be omitted.Additional method elements may also be performed as desired.

At 2610, in the illustrated embodiment, a computing device accesses aplurality of audio files. In some embodiments, the audio files areaccessed from a memory of the computer system, wherein the user hasrights to the accessed audio files.

At 2620, in the illustrated embodiment, a computing device generatesoutput music content by combining music content from two or more audiofiles using at least one trained machine learning algorithm. In someembodiments, the combining of the music content is determined by the atleast one trained machine learning algorithm based on the music contentwithin the two or more audio files. In some embodiments, the at leastone trained machine learning algorithm combines the music content bysequentially selecting music content from the two or more audio filesbased on the music content within the two or more audio files.

In some embodiments, the at least one trained machine learning algorithmhas been trained to select music content for upcoming beats after aspecified time based on metadata of music content played up to thespecified time. In some embodiments, the at least one trained machinelearning algorithm has further been trained to select music content forupcoming beats after the specified time based on the level of thecontrol element.

At 2630, in the illustrated embodiment, a computing device implements,on a user interface, a control element created by a user for variationof a user-specified parameter in the generated output music content,where levels of one or more audio parameters in the generated outputmusic content are determined based on a level of the control element,and where a relationship between the levels of the one or more audioparameters and the level of the control element is based on user inputduring at least one music playback session. In some embodiments, thelevel of the user-specified parameter is varied based on one or moreenvironmental conditions.

In some embodiments, the relationship between the levels of the one ormore audio parameters and the level of the control element is determinedby: playing multiple audio tracks during the at least one music playbacksession, wherein the multiple audio tracks have varying audioparameters; receiving, for each of the audio tracks, an input specifyinga user selected level of the user-specified parameter in the audiotrack; assessing, for each of the audio tracks, levels of one or moreaudio parameters in the audio track; and determining the relationshipbetween the levels of the one or more audio parameters and the level ofthe control element based on correlations between each of the userselected levels of the user-specified parameter and each of the assessedlevels of the one or more audio parameters.

In some embodiments, the relationship between the levels of the one ormore audio parameters and the level of the control element is determinedusing one or more machine learning algorithms. In some embodiments, therelationship between the levels of the one or more audio parameters andthe level of the control element is refined based on user variation ofthe level of the control element during playback of the generated outputmusic content. In some embodiments, the levels of the one or more audioparameters in the audio tracks are assessed using metadata from theaudio tracks. In some embodiments, the relationship between the levelsof the one or more audio parameters and the level of the user-specifiedparameter is further based on additional user input during one or moreadditional music playback sessions.

In some embodiments, the computing device implements, on the userinterface, at least one additional control element created by the userfor variation of an additional user-specified parameter in the generatedoutput music content where the additional user-specified parameter is asub-parameter of the user-specified parameter. In some embodiments, thegenerated output music content is modified based on user adjustment ofthe level of the control element. In some embodiments, a feedbackcontrol element is implemented on the user interface where the feedbackcontrol element allows the user to provide positive or negative feedbackon the generated output music content during playback. In someembodiments, the at least one trained machine algorithm modifiesgeneration of subsequent generated output music content based on thefeedback received during the playback.

FIG. 27 is a flow diagram method for generating music content bymodifying audio parameters, according to some embodiments. The methodshown in FIG. 27 may be used in conjunction with any of the computercircuitry, systems, devices, elements, or components disclosed herein,among others. In various embodiments, some of the method elements shownmay be performed concurrently, in a different order than shown, or maybe omitted. Additional method elements may also be performed as desired.

At 2710, in the illustrated embodiment, a computing device accesses aset of music content. In some embodiments.

At 2720, in the illustrated embodiment, a computing device generates afirst graph of an audio signal of the music content where the firstgraph is a graph of audio parameters relative to time.

At 2730, in the illustrated embodiment, a computing device generates asecond graph of the audio signal of the music content where the secondgraph is a signal graph of the audio parameters relative to beat. Insome embodiments, the second graph of the audio signal has a similarstructure to the first graph of the audio signal.

At 2740, in the illustrated embodiment, a computing device generates newmusic content from playback music content by modifying the audioparameters in the playback music content, wherein the audio parametersare modified based on a combination of the first graph and the secondgraph.

In some embodiments, the audio parameters in the first graph and thesecond graph are defined by nodes in the graphs that determine changesin properties of the audio signal. In some embodiments, generating thenew music content includes: receiving the playback music content;determining a first node in the first graph corresponding to an audiosignal in the playback music content; determining a second node in thesecond graph that corresponds to the first node; determining one or morespecified audio parameters based on the second node; and modifying oneor more properties of an audio signal in the playback music content bymodifying the specified audio parameters. In some embodiments, one ormore additional specified audio parameters are determined based on thefirst node and one or more properties of an additional audio signal inthe playback music content are modified by modifying the additionalspecified audio parameters.

In some embodiments, determining the one or more audio parametersincludes: determining a portion of the second graph to implement for theaudio parameters based on a position of the second node in the secondgraph and selecting the audio parameters from the determined portion ofthe second graph as the one or more audio specified parameters. In someembodiments, modifying the one or more specified audio parametersmodifies a portion of the playback music content that corresponds to thedetermined portion of the second graph. In some embodiments, themodified properties of the audio signal in the playback music contentinclude signal amplitude, signal frequency, or a combination thereof.

In some embodiments, one or more automations are applied to the audioparameters where at least one of the automations is a pre-programmedtemporal manipulation of at least one audio parameter. In someembodiments, one or more modulations are applied to the audio parameterswhere at least one of the modulations modifies at least one audioparameter multiplicatively on top of at least one automation.

Although specific embodiments have been described above, theseembodiments are not intended to limit the scope of the presentdisclosure, even where only a single embodiment is described withrespect to a particular feature. Examples of features provided in thedisclosure are intended to be illustrative rather than restrictiveunless stated otherwise. The above description is intended to cover suchalternatives, modifications, and equivalents as would be apparent to aperson skilled in the art having the benefit of this disclosure.

The scope of the present disclosure includes any feature or combinationof features disclosed herein (either explicitly or implicitly), or anygeneralization thereof, whether or not it mitigates any or all of theproblems addressed herein. Accordingly, new claims may be formulatedduring prosecution of this application (or an application claimingpriority thereto) to any such combination of features. In particular,with reference to the appended claims, features from dependent claimsmay be combined with those of the independent claims and features fromrespective independent claims may be combined in any appropriate mannerand not merely in the specific combinations enumerated in the appendedclaims.

What is claimed is:
 1. A method, comprising: determining, by a computersystem playback data for a music content mix, wherein the playback dataindicates characteristics of playback of the music content mix, whereinthe music content mix includes a determined combination of multipleaudio tracks; and recording, by the computer system, in an electronicblock-chain ledger data structure, information specifying individualplayback data for one or more of the multiple audio tracks in the musiccontent mix, wherein the information specifying individual playback datafor an individual audio track includes usage data for the individualaudio track and signature information associated with the individualaudio track.
 2. The method of claim 1, wherein the usage data includesat least one of: a time played for the music content mix or a number oftimes played for the music content mix.
 3. The method of claim 1,further comprising determining the information specifying individualplayback data for the individual audio track based on the playback dataof the music content mix and data identifying individual audio tracks inthe music content mix.
 4. The method of claim 1, wherein dataidentifying individual audio tracks in the music content mix isretrieved from a data store that also indicates an operation to beperformed in association with inclusion of one or more individual audiotracks, wherein the recording includes recording an indication of proofof performance of the indicated operation.
 5. The method of claim 1,further comprising identifying one or more entities associated with theindividual audio track based on the signature information and dataspecifying signature information for a plurality of entities associatedwith a plurality of audio tracks.
 6. The method of claim 5, furthercomprising determining, based on the information specifying individualplayback data recorded in the electronic block-chain ledger,remuneration for the plurality of entities associated with the pluralityof audio tracks.
 7. The method of claim 1, wherein the playback dataincludes usage data for one or more machine learning modules used togenerate the music mix.
 8. The method of claim 1, further comprisingstoring, at least temporarily by a playback device, the playback data ofthe music content mix.
 9. The method of claim 8, wherein the storedplayback data is communicated by the playback device to another computersystem periodically or in response to an event.
 10. The method of claim8, further comprising encrypting, by the playback device, the playbackdata of the music content mix.
 11. The method of claim 1, wherein theblock-chain ledger is publicly accessible and is immutable.
 12. Themethod of claim 1, further comprising: determining usage data for afirst individual audio track that is not included in the music contentmix in its original musical form.
 13. The method of claim 12, furthercomprising: generating a new audio track based on interpolating betweenvector representations of audio in at least two of the multiple audiotracks; and wherein the determining usage data is based on a distancebetween a vector representation of the first individual audio track anda vector representation of the new audio track.
 14. A non-transitorycomputer-readable medium having instructions stored thereon that areexecutable by a computing device to perform operations comprising:determining playback data of a music content mix, wherein the playbackdata is recorded by a playback device, wherein the playback dataindicates characteristics of playback of the music content mix, andwherein the music content mix includes a determined combination ofmultiple audio tracks; and recording in an electronic block-chain ledgerdata structure, information specifying individual playback data for oneor more of the multiple audio tracks in the music content mix, whereinthe information specifying individual playback data for an individualaudio track includes usage data for the individual audio track andsignature information associated with the individual audio track. 15.The non-transitory computer-readable medium of claim 14, wherein themusic content mix is a continuous combination of the multiple audiotracks created by layering and sequencing of the multiple audio tracks.16. The non-transitory computer-readable medium of claim 15, whereinrecording the information specifying individual playback data includesrecording information specifying playback data of layers and sequencesin the multiple audio tracks.
 17. The non-transitory computer-readablemedium of claim 14, wherein the music content mix includes content thatis a blended combination of multiple audio tracks, and wherein theblended combination is created by: interpolating between vectorrepresentations of audio in at least two of the multiple audio tracks;and generating the music content mix by using an inverse transformationfrom the vector representations.
 18. The non-transitorycomputer-readable medium of claim 17, wherein the playback data includesat least one of: a time played for the music content mix or a number oftimes played for the music content mix, and wherein the time played orthe number of times played for the individual audio tracks is determinedby incrementing, for the at least two of the multiple audio tracks, aratio of a Euclidean distance from the interpolated vectorrepresentations and vectors in the at least two of the multiple audiotracks.
 19. An apparatus, comprising: one or more processors; and one ormore memories having program instructions stored thereon that areexecutable by the one or more processors to: determine playback data ofa music content mix, wherein the playback data is recorded by a playbackdevice, wherein the playback data indicates characteristics of playbackof the music content mix, and wherein the music content mix includes adetermined combination of multiple audio tracks; and record in anelectronic block-chain ledger data structure, information specifyingindividual playback data for one or more of the multiple audio tracks inthe music content mix, wherein the information specifying individualplayback data for an individual audio track includes usage data for theindividual audio track and signature information associated with theindividual audio track.
 20. The apparatus of claim 19, wherein theblock-chain ledger is publicly accessible and is immutable.